Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_33_1/doc/html/threads/design.html @ 12

Last change on this file since 12 was 12, checked in by landauf, 17 years ago

added boost

File size: 11.7 KB
Line 
1<html>
2<head>
3<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4<title>Design</title>
5<link rel="stylesheet" href="../boostbook.css" type="text/css">
6<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
7<link rel="start" href="../index.html" title="The Boost C++ Libraries">
8<link rel="up" href="../threads.html" title="Chapter 12. Boost.Threads">
9<link rel="prev" href="../threads.html" title="Chapter 12. Boost.Threads">
10<link rel="next" href="concepts.html" title="Concepts">
11</head>
12<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
13<table cellpadding="2" width="100%">
14<td valign="top"><img alt="boost.png (6897 bytes)" width="277" height="86" src="../../../boost.png"></td>
15<td align="center"><a href="../../../index.htm">Home</a></td>
16<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
17<td align="center"><a href="../../../people/people.htm">People</a></td>
18<td align="center"><a href="../../../more/faq.htm">FAQ</a></td>
19<td align="center"><a href="../../../more/index.htm">More</a></td>
20</table>
21<hr>
22<div class="spirit-nav">
23<a accesskey="p" href="../threads.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../threads.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="concepts.html"><img src="../images/next.png" alt="Next"></a>
24</div>
25<div class="section" lang="en">
26<div class="titlepage"><div><div><h3 class="title">
27<a name="threads.design"></a>Design</h3></div></div></div>
28<div class="toc"><dl>
29<dt><span class="section"><a href="design.html#threads.design.goals">Goals</a></span></dt>
30<dt><span class="section"><a href="design.html#id2775596">Iterative Phases</a></span></dt>
31<dt><span class="section"><a href="design.html#id2775636">Phase 1, Synchronization Primitives</a></span></dt>
32<dt><span class="section"><a href="design.html#threads.design.phase2">Phase 2, Thread Management and Thread Specific Storage</a></span></dt>
33<dt><span class="section"><a href="design.html#id2775808">The Next Phase</a></span></dt>
34</dl></div>
35<p>With client/server and three-tier architectures becoming common place
36  in today's world, it's becoming increasingly important for programs to be
37  able to handle parallel processing. Modern day operating systems usually
38  provide some support for this through native thread APIs. Unfortunately,
39  writing portable code that makes use of parallel processing in C++ is made
40  very difficult by a lack of a standard interface for these native APIs.
41  Further, these APIs are almost universally C APIs and fail to take
42  advantage of C++'s strengths, or to address concepts unique to C++, such as
43  exceptions.</p>
44<p>The <span class="bold"><strong>Boost.Threads</strong></span> library is an attempt to define a portable interface
45  for writing parallel processes in C++.</p>
46<div class="section" lang="en">
47<div class="titlepage"><div><div><h4 class="title">
48<a name="threads.design.goals"></a>Goals</h4></div></div></div>
49<p>The <span class="bold"><strong>Boost.Threads</strong></span> library has several goals that should help to set
50        it apart from other solutions. These goals are listed in order of precedence
51        with full descriptions below.
52    </p>
53<div class="variablelist"><dl>
54<dt><span class="term">Portability</span></dt>
55<dd><p><span class="bold"><strong>Boost.Threads</strong></span> was designed to be highly portable. The goal is
56                  for the interface to be easily implemented on any platform that
57                  supports threads, and possibly even on platforms without native thread
58                  support.</p></dd>
59<dt><span class="term">Safety</span></dt>
60<dd>
61<p><span class="bold"><strong>Boost.Threads</strong></span> was designed to be as safe as possible. Writing
62                  <a href="../threads.html#threads.glossary.thread-safe">thread-safe</a>
63                  code is very difficult and successful libraries must strive to
64                  insulate the programmer from dangerous constructs as much as
65                  possible. This is accomplished in several ways:
66          </p>
67<div class="itemizedlist"><ul type="disc">
68<li><p>C++ language features are used to make correct usage easy
69                          (if possible) and error-prone usage impossible or at least more
70                          difficult. For example, see the <a href="concepts.html#threads.concepts.Mutex" title="Mutex Concept">Mutex</a> and <a href="concepts.html#threads.concepts.Lock" title="Lock Concept">Lock</a> designs, and note
71                          how they interact.</p></li>
72<li><p>Certain traditional concurrent programming features are
73                          considered so error-prone that they are not provided at all. For
74                          example, see <a href="rationale.html#threads.rationale.events" title="Rationale for not providing Event Variables">the section called &#8220;Rationale for not providing <span class="emphasis"><em>Event Variables</em></span>&#8221;</a>.</p></li>
75<li><p>Dangerous features, or features which may be misused, are
76              identified as such in the documentation to make users aware of
77              potential pitfalls.</p></li>
78</ul></div>
79</dd>
80<dt><span class="term">Flexibility</span></dt>
81<dd><p><span class="bold"><strong>Boost.Threads</strong></span> was designed to be flexible. This goal is often
82                  at odds with <span class="emphasis"><em>safety</em></span>. When functionality might be
83                  compromised by the desire to keep the interface safe, <span class="bold"><strong>Boost.Threads</strong></span>
84                  has been designed to provide the functionality, but to make it's use
85                  prohibitive for general use. In other words, the interfaces have been
86                  designed such that it's usually obvious when something is unsafe, and
87                  the documentation is written to explain why.</p></dd>
88<dt><span class="term">Efficiency</span></dt>
89<dd><p><span class="bold"><strong>Boost.Threads</strong></span> was designed to be as efficient as
90                  possible. When building a library on top of another library there is
91                  always a danger that the result will be so much slower than the
92                  "native" API that programmers are inclined to ignore the higher level
93                  API. <span class="bold"><strong>Boost.Threads</strong></span> was designed to minimize the chances of this
94                  occurring. The interfaces have been crafted to allow an implementation
95                  the greatest chance of being as efficient as possible. This goal is
96                  often at odds with the goal for <span class="emphasis"><em>safety</em></span>. Every
97                  effort was made to ensure efficient implementations, but when in
98                  conflict <span class="emphasis"><em>safety</em></span> has always taken
99                  precedence.</p></dd>
100</dl></div>
101</div>
102<div class="section" lang="en">
103<div class="titlepage"><div><div><h4 class="title">
104<a name="id2775596"></a>Iterative Phases</h4></div></div></div>
105<p>Another goal of <span class="bold"><strong>Boost.Threads</strong></span> was to take a dynamic, iterative
106        approach in its development. The computing industry is still exploring the
107        concepts of parallel programming. Most thread libraries supply only simple
108        primitive concepts for thread synchronization. These concepts are very
109        simple, but it is very difficult to use them safely or to provide formal
110        proofs for constructs built on top of them. There has been a lot of research
111        into other concepts, such as in "Communicating Sequential Processes."
112        <span class="bold"><strong>Boost.Threads</strong></span> was designed in iterative steps, with each step providing
113        the building blocks necessary for the next step and giving the researcher
114        the tools necessary to explore new concepts in a portable manner.</p>
115<p>Given the goal of following a dynamic, iterative approach
116        <span class="bold"><strong>Boost.Threads</strong></span> shall go through several growth cycles. Each phase in its
117        development shall be roughly documented here.</p>
118</div>
119<div class="section" lang="en">
120<div class="titlepage"><div><div><h4 class="title">
121<a name="id2775636"></a>Phase 1, Synchronization Primitives</h4></div></div></div>
122<p>Boost is all about providing high quality libraries with
123        implementations for many platforms. Unfortunately, there's a big problem
124        faced by developers wishing to supply such high quality libraries, namely
125        thread-safety. The C++ standard doesn't address threads at all, but real
126        world programs often make use of native threading support. A portable
127        library that doesn't address the issue of thread-safety is therefore not
128        much help to a programmer who wants to use the library in his multithreaded
129        application. So there's a very great need for portable primitives that will
130        allow the library developer to create <a href="../threads.html#threads.glossary.thread-safe">thread-safe</a>
131        implementations. This need far out weighs the need for portable methods to
132        create and manage threads.</p>
133<p>Because of this need, the first phase of <span class="bold"><strong>Boost.Threads</strong></span> focuses
134        solely on providing portable primitive concepts for thread
135        synchronization. Types provided in this phase include the
136        <code class="computeroutput"><a href="../mutex.html" title="Class mutex">boost::mutex</a></code>,
137        <code class="computeroutput"><a href="../try_mutex.html" title="Class try_mutex">boost::try_mutex</a></code>,
138        <code class="computeroutput"><a href="../timed_mutex.html" title="Class timed_mutex">boost::timed_mutex</a></code>,
139        <code class="computeroutput"><a href="../recursive_mutex.html" title="Class recursive_mutex">boost::recursive_mutex</a></code>,
140        <code class="computeroutput"><a href="../recursive_try_mutex.html" title="Class recursive_try_mutex">boost::recursive_try_mutex</a></code>,
141        <code class="computeroutput"><a href="../recursive_timed_mutex.html" title="Class recursive_timed_mutex">boost::recursive_timed_mutex</a></code>, and
142        <code class="computeroutput"><a href="../lock_error.html" title="Class lock_error">boost::lock_error</a></code>. These are considered the "core"
143        synchronization primitives, though there are others that will be added in
144        later phases.</p>
145</div>
146<div class="section" lang="en">
147<div class="titlepage"><div><div><h4 class="title">
148<a name="threads.design.phase2"></a>Phase 2, Thread Management and Thread Specific Storage</h4></div></div></div>
149<p>This phase addresses the creation and management of threads and
150    provides a mechanism for thread specific storage (data associated with a
151    thread instance). Thread management is a tricky issue in C++, so this
152    phase addresses only the basic needs of multithreaded program. Later
153    phases are likely to add additional functionality in this area. This
154    phase of <span class="bold"><strong>Boost.Threads</strong></span> adds the <code class="computeroutput"><a href="../thread.html" title="Class thread">boost::thread</a></code> and
155        <code class="computeroutput"><a href="../thread_specific_ptr.html" title="Class thread_specific_ptr">boost::thread_specific_ptr</a></code> types. With these
156        additions the <span class="bold"><strong>Boost.Threads</strong></span> library can be considered minimal but
157        complete.</p>
158</div>
159<div class="section" lang="en">
160<div class="titlepage"><div><div><h4 class="title">
161<a name="id2775808"></a>The Next Phase</h4></div></div></div>
162<p>The next phase will address more advanced synchronization concepts,
163    such as read/write mutexes and barriers.</p>
164</div>
165</div>
166<table width="100%"><tr>
167<td align="left"><small><p>Last revised: July 17, 2004 at 04:33:59 GMT</p></small></td>
168<td align="right"><small>Copyright © 2001-2003 William E. Kempf</small></td>
169</tr></table>
170<hr>
171<div class="spirit-nav">
172<a accesskey="p" href="../threads.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../threads.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="concepts.html"><img src="../images/next.png" alt="Next"></a>
173</div>
174</body>
175</html>
Note: See TracBrowser for help on using the repository browser.