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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Frequently Asked Questions</title>
<link rel="stylesheet" href="../boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
<link rel="start" href="../index.html" title="The Boost C++ Libraries">
<link rel="up" href="../threads.html" title="Chapter 12. Boost.Threads">
<link rel="prev" href="../xtime.html" title="Struct xtime">
<link rel="next" href="../thread/configuration.html" title="Configuration">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table cellpadding="2" width="100%">
<td valign="top"><img alt="boost.png (6897 bytes)" width="277" height="86" src="../../../boost.png"></td>
<td align="center"><a href="../../../index.htm">Home</a></td>
<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
<td align="center"><a href="../../../people/people.htm">People</a></td>
<td align="center"><a href="../../../more/faq.htm">FAQ</a></td>
<td align="center"><a href="../../../more/index.htm">More</a></td>
</table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="../xtime.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="../thread/configuration.html"><img src="../images/next.png" alt="Next"></a>
</div>
<div class="section" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="threads.faq"></a>Frequently Asked Questions</h3></div></div></div>
<div class="qandaset">
<dl>
<dt>1. <a href="faq.html#id2786577">Are lock objects thread safe?</a>
</dt>
<dt>2. <a href="faq.html#id2786619">Why was Boost.Threads modeled after (specific library
name)?</a>
</dt>
<dt>3. <a href="faq.html#id2786652">Why wasn't Boost.Threads modeled after (specific library
name)?</a>
</dt>
<dt>4. <a href="faq.html#id2786688">Why do Mutexes
have noncopyable semantics?</a>
</dt>
<dt>5. <a href="faq.html#id2786718">How can you prevent deadlock from occurring when
a thread must lock multiple mutexes?</a>
</dt>
<dt>6. <a href="faq.html#id2786744">Don't noncopyable Mutex semantics mean that a
class with a mutex member will be noncopyable as well?</a>
</dt>
<dt>7. <a href="faq.html#id2786812">How can you lock a Mutex member in a const member
function, in order to implement the Monitor Pattern?</a>
</dt>
<dt>8. <a href="faq.html#id2786850">Why supply boost::condition variables rather than
event variables?</a>
</dt>
<dt>9. <a href="faq.html#id2786907">Why isn't thread cancellation or termination provided?</a>
</dt>
<dt>10. <a href="faq.html#id2786924">Is it safe for threads to share automatic storage duration (stack)
objects via pointers or references?</a>
</dt>
<dt>11. <a href="faq.html#id2786940">Why has class semaphore disappeared?</a>
</dt>
</dl>
<table border="0" summary="Q and A Set">
<col align="left" width="1%">
<tbody>
<tr class="question">
<td align="left" valign="top">
<a name="id2786577"></a><a name="id2786578"></a><b>1.</b>
</td>
<td align="left" valign="top"><p>Are lock objects <a href="../threads.html#threads.glossary.thread-safe">thread safe</a>?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p><span class="bold"><strong>No!</strong></span> Lock objects are not meant to
be shared between threads. They are meant to be short-lived objects
created on automatic storage within a code block. Any other usage is
just likely to lead to errors and won't really be of actual benefit anyway.
Share <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutexes</a>, not
Locks. For more information see the <a href="rationale.html#threads.rationale.locks" title="Rationale for the Lock Design">rationale</a> behind the
design for lock objects.</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786619"></a><a name="id2786620"></a><b>2.</b>
</td>
<td align="left" valign="top"><p>Why was <span class="bold"><strong>Boost.Threads</strong></span> modeled after (specific library
name)?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>It wasn't. <span class="bold"><strong>Boost.Threads</strong></span> was designed from scratch. Extensive
design discussions involved numerous people representing a wide range of
experience across many platforms. To ensure portability, the initial
implements were done in parallel using POSIX Threads and the Win32
threading API. But the <span class="bold"><strong>Boost.Threads</strong></span> design is very much in the spirit
of C++, and thus doesn't model such C based APIs.</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786652"></a><a name="id2786653"></a><b>3.</b>
</td>
<td align="left" valign="top"><p>Why wasn't <span class="bold"><strong>Boost.Threads</strong></span> modeled after (specific library
name)?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>Existing C++ libraries either seemed dangerous (often failing to
take advantage of prior art to reduce errors) or had excessive
dependencies on library components unrelated to threading. Existing C
libraries couldn't meet our C++ requirements, and were also missing
certain features. For instance, the WIN32 thread API lacks condition
variables, even though these are critical for the important Monitor
pattern [<span class="citation"><a href="../threads.html#threads.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>].</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786688"></a><a name="id2786689"></a><b>4.</b>
</td>
<td align="left" valign="top"><p>Why do <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutexes</a>
have noncopyable semantics?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>To ensure that <a href="../threads.html#threads.glossary.deadlock">deadlocks</a> don't occur. The
only logical form of copy would be to use some sort of shallow copy
semantics in which multiple mutex objects could refer to the same mutex
state. This means that if ObjA has a mutex object as part of its state
and ObjB is copy constructed from it, then when ObjB::foo() locks the
mutex it has effectively locked ObjA as well. This behavior can result
in deadlock. Other copy semantics result in similar problems (if you
think you can prove this to be wrong then supply us with an alternative
and we'll reconsider).</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786718"></a><a name="id2786720"></a><b>5.</b>
</td>
<td align="left" valign="top"><p>How can you prevent <a href="../threads.html#threads.glossary.deadlock">deadlock</a> from occurring when
a thread must lock multiple mutexes?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>Always lock them in the same order. One easy way of doing this is
to use each mutex's address to determine the order in which they are
locked. A future <span class="bold"><strong>Boost.Threads</strong></span> concept may wrap this pattern up in a
reusable class.</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786744"></a><a name="id2786745"></a><b>6.</b>
</td>
<td align="left" valign="top"><p>Don't noncopyable <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutex</a> semantics mean that a
class with a mutex member will be noncopyable as well?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top">
<p>No, but what it does mean is that the compiler can't generate a
copy constructor and assignment operator, so they will have to be coded
explicitly. This is a <span class="bold"><strong>good thing</strong></span>,
however, since the compiler generated operations would not be <a href="../threads.html#threads.glossary.thread-safe">thread-safe</a>. The following
is a simple example of a class with copyable semantics and internal
synchronization through a mutex member.</p>
<pre class="programlisting">
class counter
{
public:
// Doesn't need synchronization since there can be no references to *this
// until after it's constructed!
explicit counter(int initial_value)
: m_value(initial_value)
{
}
// We only need to synchronize other for the same reason we don't have to
// synchronize on construction!
counter(const counter& other)
{
boost::mutex::scoped_lock scoped_lock(other.m_mutex);
m_value = other.m_value;
}
// For assignment we need to synchronize both objects!
const counter& operator=(const counter& other)
{
if (this == &other)
return *this;
boost::mutex::scoped_lock lock1(&m_mutex < &other.m_mutex ? m_mutex : other.m_mutex);
boost::mutex::scoped_lock lock2(&m_mutex > &other.m_mutex ? m_mutex : other.m_mutex);
m_value = other.m_value;
return *this;
}
int value() const
{
boost::mutex::scoped_lock scoped_lock(m_mutex);
return m_value;
}
int increment()
{
boost::mutex::scoped_lock scoped_lock(m_mutex);
return ++m_value;
}
private:
mutable boost::mutex m_mutex;
int m_value;
};
</pre>
</td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786812"></a><a name="id2786813"></a><b>7.</b>
</td>
<td align="left" valign="top"><p>How can you lock a <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutex</a> member in a const member
function, in order to implement the Monitor Pattern?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>The Monitor Pattern [<span class="citation"><a href="../threads.html#threads.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>] mutex
should simply be declared as mutable. See the example code above. The
internal state of mutex types could have been made mutable, with all
lock calls made via const functions, but this does a poor job of
documenting the actual semantics (and in fact would be incorrect since
the logical state of a locked mutex clearly differs from the logical
state of an unlocked mutex). Declaring a mutex member as mutable clearly
documents the intended semantics.</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786850"></a><a name="id2786851"></a><b>8.</b>
</td>
<td align="left" valign="top"><p>Why supply <code class="computeroutput"><a href="../condition.html" title="Class condition">boost::condition</a></code> variables rather than
event variables?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>Condition variables result in user code much less prone to <a href="../threads.html#threads.glossary.race-condition">race conditions</a> than
event variables. See <a href="rationale.html#threads.rationale.events" title="Rationale for not providing Event Variables">the section called “Rationale for not providing <span class="emphasis"><em>Event Variables</em></span>”</a>
for analysis. Also see [<span class="citation"><a href="../threads.html#threads.bib.Hoare74">Hoare74</a></span>] and [<span class="citation"><a href="../threads.html#threads.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>].
</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786907"></a><a name="id2786908"></a><b>9.</b>
</td>
<td align="left" valign="top"><p>Why isn't thread cancellation or termination provided?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>There's a valid need for thread termination, so at some point
<span class="bold"><strong>Boost.Threads</strong></span> probably will include it, but only after we can find a
truly safe (and portable) mechanism for this concept.</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786924"></a><a name="id2786925"></a><b>10.</b>
</td>
<td align="left" valign="top"><p>Is it safe for threads to share automatic storage duration (stack)
objects via pointers or references?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>Only if you can guarantee that the lifetime of the stack object
will not end while other threads might still access the object. Thus the
safest practice is to avoid sharing stack objects, particularly in
designs where threads are created and destroyed dynamically. Restrict
sharing of stack objects to simple designs with very clear and
unchanging function and thread lifetimes. (Suggested by Darryl
Green).</p></td>
</tr>
<tr class="question">
<td align="left" valign="top">
<a name="id2786940"></a><a name="id2786941"></a><b>11.</b>
</td>
<td align="left" valign="top"><p>Why has class semaphore disappeared?</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"><b></b></td>
<td align="left" valign="top"><p>Semaphore was removed as too error prone. The same effect can be
achieved with greater safety by the combination of a mutex and a
condition variable.</p></td>
</tr>
</tbody>
</table>
</div>
</div>
<table width="100%"><tr>
<td align="left"><small><p>Last revised: July 17, 2004 at 04:33:59 GMT</p></small></td>
<td align="right"><small>Copyright © 2001-2003 William E. Kempf</small></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="../xtime.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="../thread/configuration.html"><img src="../images/next.png" alt="Next"></a>
</div>
</body>
</html>
|
