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
|
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=iso-8859-1">
<meta name="keywords" content="threads, BTL, thread library, C++">
<link rel="stylesheet" type="text/css" href="styles.css">
<title>Boost.Threads, FAQ</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 src="../../../c++boost.gif" alt="C++ Boost" width="277" height="86"></h3>
</td>
<td valign="top">
<h1 align="center">Boost.Threads</h1>
<h2 align="center">Frequently Asked Questions</h2>
</td>
</tr>
</table>
<hr>
<h2>1. Are lock objects <a href="definitions.html#Thread-safe">
thread-safe</a>?</h2>
<p><b>No!</b> 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 any way. Share <a href=
"mutex_concept.html">mutexes</a>, not locks. For more information see
the <a href="rationale.html#lock_objects">rationale</a> behind the
design for lock objects.</p>
<h2>2a. Why was Boost.Threads modeled after (specific library
name)?</h2>
<p>It wasn't. Boost.Threads 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 theWin32
threading API. But the Boost.Threads design is very much in the spirit
of C++, and thus doesn't model such C based APIs.</p>
<h2>2b. Why wasn't Boost.Threads modeled after (specific library
name)?</h2>
<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 <a href="bibliography.html#Schmidt-00">[Schmidt 00]</a>.</p>
<h2>3. Why do <a href="mutex_concept.html">Mutexes</a> have noncopyable
semantics?</h2>
<p>To ensure that <a href="definitions.html#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>
<h2>4. How can you prevent <a href="definitions.html#Deadlock">
deadlock</a> from occurring when a thread must lock multiple
mutexes?</h2>
<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 Boost.Threads concept may wrap this pattern up in a
reusable class.</p>
<h2>5. Don't noncopyable <a href="mutex_concept.html">mutex</a>
semantics mean that a class with a mutex member will be noncopyable as
well?</h2>
<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 <b>good thing</b>, however, since the compiler
generated operations would not be <a href=
"definitions.html#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 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 syncronize 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>
<h2>6. How can you lock a <a href="mutex_concept.html">mutex</a> member
in a const member function, in order to implement the Monitor
Pattern?</h2>
<p>The Monitor Pattern mutex <a href="bibliography.html#Schmidt-00">
[Schmidt 00]</a> 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. Declaring a mutex member
as mutable clearly documentations the intended semantics.</p>
<h2>7. Why supply <a href="condition.html">condition variables</a>
rather than <a href="rationale.html#Events">event variables</a>?</h2>
<p>Condition variables result in user code much less prone to <a href=
"definitions.html#Race condition">race conditions</a> than event
variables. See <a href="rationale.html#Events">Rationale</a> for
analysis. Also see <a href="bibliography.html#Hoare-74">[Hoare74]</a>
and <a href="bibliography.html#Schmidt-00">[Schmidt 00]</a>.</p>
<h2>8. Why isn't thread cancellation or termination provided?</h2>
<p>There's a valid need for thread termination, so at some point
Boost.Threads probably will include it, but only after we can find a
truly safe (and portable) mechanism for this concept.</p>
<h2>9. Is it safe for threads to share automatic storage duration
(stack) objects via pointers or references?</h2>
<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>
<h2>10. Why has class semaphore disappeared?</h2>
<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>
<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>
|
