mirror of
https://github.com/boostorg/thread.git
synced 2026-01-22 17:52:18 +00:00
160 lines
8.9 KiB
HTML
160 lines
8.9 KiB
HTML
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link rel="stylesheet" type="text/css" href="../../../boost.css">
|
|
<title>Boost.Threads - Introduction to Design</title>
|
|
</head>
|
|
<body link="#0000ff" vlink="#800080">
|
|
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
|
|
"header">
|
|
<tr>
|
|
<td valign="top" width="300">
|
|
<h3><a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../c++boost.gif" border="0"></a></h3>
|
|
</td>
|
|
<td valign="top">
|
|
<h1 align="center">Boost.Threads</h1>
|
|
<h2 align="center">Introduction to Design</h2>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<hr>
|
|
<dl class="page-index">
|
|
<dt><a href="#motivation">Motivation</a></dt>
|
|
<dt><a href="#goals">Goals</a></dt>
|
|
<dt><a href="#phases">Iterative Phases</a></dt>
|
|
<dl class="page-index">
|
|
<dt><a href="#phase1">Phase 1, Synchronization Primitives</a></dt>
|
|
<dt><a href="#phase2">Phase 2, Thread Management and Thread Specific Storage</a></dt>
|
|
<dt><a href="#next-phase">The Next Phase</a></dt>
|
|
</dl>
|
|
</dl>
|
|
<h2><a name="motivation"></a>Motivation</h2>
|
|
<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>
|
|
<h2><a name="goals"></a>Goals</h2>
|
|
<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. In other words, the interfaces have been designed such that it's usually
|
|
obvious when something is unsafe, and the documentation is written to explain
|
|
why.</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>
|
|
<h2><a name="phases"></a>Iterative Phases</h2>
|
|
<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. 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>
|
|
<h3><a name="phase1"></a>Phase 1, Synchronization Primitives</h3>
|
|
<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 multithreaded 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>
|
|
and <a href="exceptions.html#class-lock_error">lock_error</a>. These are considered
|
|
the "core" synchronization primitives, though there are others that
|
|
will be added in later phases.</p>
|
|
<h3><a name="phase2"></a>Phase 2, Thread Management and Thread Specific Storage</h3>
|
|
<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 multithreaded 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="tss.html#class-thread_specific_ptr">thread_specific_ptr</a> types.
|
|
With these additions the <b>Boost.Threads</b> library can be considered minimal
|
|
but complete.</p>
|
|
<h3><a name="next-phase"></a>The Next Phase</h3>
|
|
<p>The next phase will address more advanced synchronization concepts, such as
|
|
read/write mutexes and barriers.</p>
|
|
<hr>
|
|
<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:wekempf@cox.net">William E. Kempf</a> 2001-2002.
|
|
All Rights Reserved.</i></p>
|
|
<p>Permission to use, copy, modify, distribute and sell this software and its
|
|
documentation for any purpose is hereby granted without fee, provided that the
|
|
above copyright notice appear in all copies and that both that copyright notice
|
|
and this permission notice appear in supporting documentation. William E. Kempf
|
|
makes no representations about the suitability of this software for any purpose.
|
|
It is provided "as is" without express or implied warranty.</p>
|
|
</body>
|
|
</html>
|