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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Boost.Threads Overview</title>
</head>
<body>
<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">Overview</h2>
</td>
</tr>
</table>
<p><a href="#Introduction">Introduction</a><br>
<a href="#Dangers">Dangers</a><br>
<a href="#Library">C++ Standard Library usage</a><br>
<a href="#Common">Common requirements</a></p>
<h2><a name="Introduction">Introduction</a></h2>
<p>Boost.Threads allows C++ programs to execute as multiple,
asynchronous, independent, threads-of-execution. Each thread has its
own machine state including program instruction counter and registers.
Programs which execute as multiple threads are called multi-threaded
programs to distinguish them from traditional single-threaded programs.
<a href="definitions.html">Definitions</a> gives a more complete
description of the multi-threading execution environment.</p>
<p>Multi-threading provides several advantages:</p>
<ul>
<li>Programs which would otherwise block waiting for some external
event can continue to respond if the blocking operation is placed
in a separate thread. Multi-threading is usually an absolute
requirement for these programs.</li>
</ul>
<ul>
<li>Well-designed multi-threaded programs may execute faster than
single-threaded programs, particularly on multi-processor hardware.
Note, however, that poorly-designed multi-threaded programs are
often slower that single-threaded programs.</li>
</ul>
<ul>
<li>Some program designs may be easier to formulate using a
multi-threaded approach. After all, the real world is
asynchronous!</li>
</ul>
<h2><a name="Dangers">Dangers</a></h2>
<p>Beyond the errors which can occur in single-threaded programs,
multi-threaded programs are subject to additional errors:</p>
<ul>
<li><a href="definitions.html#Race condition">Race
conditions</a>.</li>
<li><a href="definitions.html#Deadlock">Deadlock</a> (sometimes
called "deadly embrace")</li>
<li><a href="definitions.html#Priority failure">Priority
failures</a> (priority inversion, infinite overtaking, starvation,
etc.)</li>
</ul>
<p>Every multi-threaded program must be designed carefully to avoid
race conditions and deadlock. These aren't rare or exotic failures
- they are virtually guaranteed to occur unless multi-threaded code is
designed to avoid them. Priority failures are somewhat less common, but
are none-the-less serious.</p>
<p>The <a href="introduction.html">Boost.Threads design</a> attempts to
minimize these errors, but they will still occur unless the programmer
proactively designs to avoid them.</p>
<h3>Testing and debugging considerations</h3>
<p>Multi-threaded programs are non-deterministic. In other words, the
same program with the same input data may follow different execution
paths each time it is invoked. That can make testing and debugging a
nightmare:</p>
<ul>
<li>Failures are often not repeatable.</li>
<li>Probe effect causes debuggers to produce very different results
from non-debug uses.</li>
<li>Debuggers require special support to show thread state.</li>
<li>Tests on a single processor system may give no indication of
serious errors which would appear on multiprocessor systems, and
visa versa. Thus test cases should include a varying number of
processors.</li>
<li>For programs which create a varying number of threads according
to workload, tests which don't span the full range of
possibilities may miss serious errors.</li>
</ul>
<h3>Getting a head start</h3>
<p>Although it might appear that multi-threaded programs are inherently
unreliable, many reliable multi-threaded programs do exist.
Multi-threading techniques are known which lead to reliable
programs.</p>
<p>Design patterns for reliable multi-threaded programs, including the
important <i>monitor</i> pattern, are presented in <cite>
Pattern-Oriented Software Architecture Volume 2 - Patterns for
Concurrent and Networked Objects</cite> [<a href=
"bibliography.html#Schmidt-00">Schmidt 00</a>]. Many important
multi-threading programming considerations (independent of threading
library) are discussed in <cite>Programming with POSIX Threads</cite>
[<a href="bibliography.html#Butenhof-97">Butenhof 97</a>].</p>
<p>Doing some reading before attempting multi-threaded designs will give
you a head start toward reliable multi-threaded programs.</p>
<h2><a name="Library">C++ Standard Library usage in multi-threaded
programs</a></h2>
<h3>Runtime libraries</h3>
<p><b>Warning:</b> Multi-threaded programs such as those using <b>
Boost.Threads</b> must link to <a href="definitions.html#Thread-safe">
thread-safe</a> versions of all runtime libraries used by the program,
including the runtime library for the C++ Standard Library. Otherwise
<a href="definitions.html#Race condition">race conditions</a> will
occur when multiple threads simultaneously execute runtime library
functions for <i>new</i>, <i>delete</i>, or other language features
which imply shared state.</p>
<h3>Potentially non-thread-safe functions</h3>
<p>Certain C++ Standard Library functions inherited from C are
particular problems because they hold internal state between calls:</p>
<ul>
<li>rand</li>
<li>strtok</li>
<li>asctime</li>
<li>ctime</li>
<li>gmtime</li>
<li>localtime</li>
</ul>
<p>It is possible to write thread-safe implementations of these by
using <a href="thread_specific_ptr.html">thread-specific storage</a>,
and several C++ compiler vendors do just that. The technique is
well-know and is explained in [<a href=
"bibliography.html#Butenhof-97">Buttenhof-97</a>].</p>
<p>But at least one vendor (HP-UX) does not provide thread-safe
implementations of the above functions in their otherwise thread-safe
runtime library. Instead they provide replacement functions with
different names and arguments.</p>
<p><b>Recommendation:</b> For the most portable, yet thread-safe code,
use Boost replacements for the problem functions. See the <a href=
"../../random/index.html">Boost Random Number Library</a> and <a href=
"../../tokenizer/index.htm">Boost Tokenizer Library</a>.</p>
<h2><a name="Common">Common</a> requirements for all Boost.Threads
components</h2>
<h3>Exceptions</h3>
<p><b>Boost.Threads</b> destructors never throw exceptions. Unless
otherwise specified, other <b>Boost.Threads</b> functions that do not
have an exception-specification may throw implementation-defined
exceptions.</p>
<p>In particular, <b>Boost.Threads</b> reports failure to allocate
storage by throwing an exception of type std::bad_alloc, or a class
derived from std::bad_alloc, failure to obtain thread resources other
than memory by throwing an exception of type <a href=
"thread_resource_error.html">boost::thread_resource_error</a>, and
certain lock related failures by throwing an exception of type <a href=
"lock_error.html">boost::lock_error</a></p>
<p><b>Rationale:</b> Follows the C++ Standard Library practice of
allowing all functions except destructors or other specified functions
to throw exceptions on errors.</p>
<h3><a name="NonCopyable">NonCopyable</a> requirement</h3>
<p><b>Boost.Threads</b> classes documented as meeting the NonCopyable
requirement disallow copy construction and copy assignment. For the
sake of exposition, the synopsis of such classes show private
derivation from <a href="../../utility/utility.htm">
boost::noncopyable</a>. Users should not depend on this derivation,
however, as implementations are free to meet the NonCopyable
requirement in other ways.</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>© Copyright 2001 Beman Dawes</p>
</body>
</html>
|
