1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
<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>
|
