mirror of
https://github.com/boostorg/thread.git
synced 2026-01-23 06:02:14 +00:00
152 lines
7.7 KiB
HTML
152 lines
7.7 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 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><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. For example, see <a href="semaphore.html#Danger">Semaphore</a>.</p>
|
|
</li>
|
|
</ul>
|
|
<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><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="file:///c:/boost/site/libs/thread/doc/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="semaphore.html">semaphore</a>, <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 -->03 September, 2001<!--webbot bot="Timestamp" endspan i-checksum="39333" -->
|
|
</p>
|
|
|
|
<p><i>© Copyright <A href="mailto:williamkempf@hotmail.com">William E. Kempf</a>
|
|
2001 all rights reserved.</i></p>
|
|
|
|
</body>
|
|
</html>
|