mirror of
https://github.com/boostorg/thread.git
synced 2026-01-22 17:52:18 +00:00
195 lines
9.3 KiB
HTML
195 lines
9.3 KiB
HTML
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=iso-8859-1">
|
|
<meta name="keywords" content="threads, BTL, thread library, C++">
|
|
|
|
<title>Boost.Threads, Introduction</title>
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
|
|
<table summary="header" border="0" cellpadding="7" cellspacing="0"
|
|
width="100%">
|
|
<tr>
|
|
<td valign="top" width="300">
|
|
<h3><img height="86" alt="C++ Boost" src=
|
|
"../../../c++boost.gif" width="277"></h3>
|
|
</td>
|
|
|
|
<td valign="top">
|
|
<h1 align="center">Boost.Threads</h1>
|
|
|
|
<h2 align="center">Introduction</h2>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<hr>
|
|
|
|
<h3>Motivation</h3>
|
|
|
|
<p>With client/server and three-tier architectures becoming common
|
|
place in today's world, it's becoming increasingly important
|
|
for programs to be able to handle parallel processing. Modern day
|
|
operating systems usually provide some support for this through native
|
|
thread APIs. Unfortunately, writing portable code that makes use of
|
|
parallel processing in C++ is made very difficult by a lack of a
|
|
standard interface for these native APIs. Further, these APIs are
|
|
almost universally C APIs and fail to take advantage of C++'s
|
|
strengths, or to address C++'s issues.</p>
|
|
|
|
<p>The <b>Boost.Threads</b> library is an attempt to define a portable
|
|
interface for writing parallel processes in C++.</p>
|
|
|
|
<h3>Goals</h3>
|
|
|
|
<p>The <b>Boost.Threads</b> library has several goals that should help
|
|
to set it apart from other solutions. These goals are listed in order
|
|
of precedence with full descriptions below.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<b>Portability</b>
|
|
|
|
<p><b>Boost.Threads</b> was designed to be highly portable. The
|
|
goal is for the interface to be easily implemented on any
|
|
platform that supports threads, and possibly even on platforms
|
|
without native thread support.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<b>Safety</b>
|
|
|
|
<p><b>Boost.Threads</b> was designed to be as safe as possible.
|
|
Writing <a href="definitions.html#Thread-safe">thread-safe</a>
|
|
code is very difficult and successful libraries must strive to
|
|
insulate the programmer from dangerous constructs as much as
|
|
possible. This is accomplished in several ways:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p align="left">C++ language features are used make
|
|
correct usage easy (if possible, the default) and
|
|
error-prone impossible or at least more difficult. For
|
|
example, see the <a href="mutex_concept.html">Mutex</a>
|
|
and <a href="lock_concept.html">Lock</a> designs, and
|
|
how note how they interact.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p align="left">Certain traditional concurrent
|
|
programming features are considered so error-prone that
|
|
they are not provided at all. For example, see the <a
|
|
href="rationale.html#Events">Events Not Provided</a>
|
|
rationale.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p align="left">Dangerous features, or features which
|
|
may be misused, are identified as such in the
|
|
documentation to make users aware of potential
|
|
pitfalls.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<b>Flexibility</b>
|
|
|
|
<p><b>Boost.Threads</b> was designed to be flexible. This goal
|
|
is often at odds with <i>safety</i>. When functionality might
|
|
be compromised by the desire to keep the interface safe, <b>
|
|
Boost.Threads</b> has been designed to provide the
|
|
functionality, but to make it's use prohibitive for general
|
|
use.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<b>Efficiency</b>
|
|
|
|
<p><b>Boost.Threads</b> was designed to be as efficient as
|
|
possible. When building a library on top of another library
|
|
there is always a danger that the result will be so much slower
|
|
than the "native" API that programmers are inclined
|
|
to ignore the higher level API. <b>Boost.Threads</b> was
|
|
designed to minimize the chances of this occurring. The
|
|
interfaces have been crafted to allow an implementation the
|
|
greatest chance of being as efficient as possible. This goal is
|
|
often at odds with the goal for <i>safety</i>. Every effort was
|
|
made to ensure efficient implementations, but when in conflict
|
|
<i>safety</i> has always taken precedence.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>Iterative Phases</h3>
|
|
|
|
<p>Another goal of <b>Boost.Threads</b> was to take a dynamic,
|
|
iterative approach in its development. The computing industry is still
|
|
exploring the concepts of parallel programming. Most thread libraries
|
|
supply only simple primitive concepts for thread synchronization. These
|
|
concepts are very simple, but they are very difficult to use safely or
|
|
to provide formal proofs for constructs built on top of them. Until
|
|
recently, these primitives were "state of the art" and the
|
|
only concepts available to programmers. Recently there has been a lot
|
|
of research in other concepts, such as in "Communicating
|
|
Sequential Processes." <b>Boost.Threads</b> was designed in
|
|
iterative steps, providing the building blocks necessary for the next
|
|
step, and giving the researcher the tools necessary to explore new
|
|
concepts in a portable manner.</p>
|
|
|
|
<p>Given the goal of following a dynamic, iterative approach <b>
|
|
Boost.Threads</b> shall go through several growth cycles. Each phase in
|
|
its development shall be roughly documented here.</p>
|
|
|
|
<h4>Phase 1, Synchronization Primitives</h4>
|
|
|
|
<p>Boost is all about providing high quality libraries with
|
|
implementations for many platforms. Unfortunately, there's a big
|
|
problem faced by developers wishing to supply such high quality
|
|
libraries, namely thread-safety. The C++ standard doesn't address
|
|
threads at all, but real world programs often make use of native
|
|
threading support. A portable library that doesn't address the
|
|
issue of thread-safety is there for not much help to a programmer who
|
|
wants to use the library in his multi-threaded application. So
|
|
there's a very great need for portable primitives that will allow
|
|
the library developer to create <a href="definitions.html#Thread-safe">
|
|
thread-safe</a> implementations. This need far out weighs the need for
|
|
portable methods to create and manage threads.</p>
|
|
|
|
<p>Because of this need, the first phase of <b>Boost.Threads</b>
|
|
focuses solely on providing portable primitive concepts for thread
|
|
synchronization. Types provided in this phase include the <a href="mutex.html">
|
|
mutex/try_mutex/timed_mutex</a>, <a href="recursive_mutex.html">
|
|
recursive_mutex/recursive_try_mutex/recursive_timed_mutex</a>, <a href=
|
|
"scoped_lock.html">scoped_lock</a>, <a href="scoped_try_lock.html">
|
|
scoped_try_lock</a>, <a href="scoped_timed_lock.html">
|
|
scoped_timed_lock</a> and <a href="lock_error.html">lock_error</a>.
|
|
These are considered the "core" synchronization primitives,
|
|
though there are others that will be added in later phases.</p>
|
|
|
|
<h4>Phase 2, Thread Management and Thread Specific Storage</h4>
|
|
|
|
<p>This phase addresses the creation and management of threads and
|
|
provides a mechanism for thread specific storage (data associated with
|
|
a thread instance). Thread management is a tricky issue in C++, so this
|
|
phase addresses only the basic needs of multi-threaded program. Later
|
|
phases are likely to add additional functionality in this area. This
|
|
phase of <b>Boost.Threads</b> adds the <a href="thread.html">thread</a>
|
|
and <a href="thread_specific_ptr.html">thread_specific_ptr</a> types.
|
|
With these additions the <b>Boost.Threads</b> library can be considered
|
|
minimal but complete.</p>
|
|
|
|
<h4>The Next Phase</h4>
|
|
|
|
<p>The next phase will address more advanced synchronization concepts,
|
|
such as read/write mutexes and barriers.</p>
|
|
<hr>
|
|
|
|
<p>Revised
|
|
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->05 November, 2001<!--webbot bot="Timestamp" endspan i-checksum="39359" --></p>
|
|
|
|
<p><i>© Copyright <a href="mailto:williamkempf@hotmail.com">
|
|
William E. Kempf</a> 2001 all rights reserved.</i></p>
|
|
</body>
|
|
</html>
|
|
|