Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_34_1/doc/html/thread/faq.html @ 29

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

updated boost from 1_33_1 to 1_34_1
File size: 15.4 KB
Line 
1<html>
2<head>
3<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4<title>Frequently Asked Questions</title>
5<link rel="stylesheet" href="../boostbook.css" type="text/css">
6<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
7<link rel="start" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset">
8<link rel="up" href="../thread.html" title="Chapter 15. Boost.Thread">
9<link rel="prev" href="../boost/xtime.html" title="Struct xtime">
10<link rel="next" href="configuration.html" title="Configuration">
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 C++ Libraries" 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="../boost/xtime.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../thread.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="configuration.html"><img src="../images/next.png" alt="Next"></a>
24</div>
25<div class="section" lang="en">
26<div class="titlepage"><div><div><h2 class="title" style="clear: both">
27<a name="thread.faq"></a>Frequently Asked Questions</h2></div></div></div>
28<div class="qandaset">
29<dl>
30<dt>1. <a href="faq.html#id1746688">Are lock objects thread safe?</a>
31</dt>
32<dt>2. <a href="faq.html#id1746737">Why was Boost.Thread modeled after (specific library
33                name)?</a>
34</dt>
35<dt>3. <a href="faq.html#id1746777">Why wasn't Boost.Thread modeled after (specific library
36            name)?</a>
37</dt>
38<dt>4. <a href="faq.html#id1746819">Why do Mutexes
39                have noncopyable semantics?</a>
40</dt>
41<dt>5. <a href="faq.html#id1746850">How can you prevent deadlock from occurring when
42                a thread must lock multiple mutexes?</a>
43</dt>
44<dt>6. <a href="faq.html#id1746885">Don't noncopyable Mutex semantics mean that a
45                class with a mutex member will be noncopyable as well?</a>
46</dt>
47<dt>7. <a href="faq.html#id1746934">How can you lock a Mutex member in a const member
48                function, in order to implement the Monitor Pattern?</a>
49</dt>
50<dt>8. <a href="faq.html#id1746980">Why supply boost::condition variables rather than
51                event variables?</a>
52</dt>
53<dt>9. <a href="faq.html#id1747046">Why isn't thread cancellation or termination provided?</a>
54</dt>
55<dt>10. <a href="faq.html#id1747071">Is it safe for threads to share automatic storage duration (stack)
56                objects via pointers or references?</a>
57</dt>
58<dt>11. <a href="faq.html#id1747096">Why has class semaphore disappeared?</a>
59</dt>
60<dt>12. <a href="faq.html#id1747115">Why doesn't the thread's ctor take at least a void* to pass any
61            information along with the function? All other threading libs support
62            that and it makes Boost.Threads inferiour. </a>
63</dt>
64</dl>
65<table border="0" summary="Q and A Set">
66<col align="left" width="1%">
67<tbody>
68<tr class="question">
69<td align="left" valign="top">
70<a name="id1746688"></a><a name="id1746690"></a><b>1.</b>
71</td>
72<td align="left" valign="top"><p>Are lock objects <a href="../thread.html#thread.glossary.thread-safe">thread safe</a>?</p></td>
73</tr>
74<tr class="answer">
75<td align="left" valign="top"><b></b></td>
76<td align="left" valign="top"><p><span class="bold"><strong>No!</strong></span> Lock objects are not meant to
77                be shared between threads. They are meant to be short-lived objects
78                created on automatic storage within a code block. Any other usage is
79                just likely to lead to errors and won't really be of actual benefit anyway.
80                Share <a href="concepts.html#thread.concepts.mutexes" title="Mutexes">Mutexes</a>, not
81                Locks. For more information see the <a href="rationale.html#thread.rationale.locks" title="Rationale for the Lock Design">rationale</a> behind the
82                design for lock objects.</p></td>
83</tr>
84<tr class="question">
85<td align="left" valign="top">
86<a name="id1746737"></a><a name="id1746739"></a><b>2.</b>
87</td>
88<td align="left" valign="top"><p>Why was <span class="bold"><strong>Boost.Thread</strong></span> modeled after (specific library
89                name)?</p></td>
90</tr>
91<tr class="answer">
92<td align="left" valign="top"><b></b></td>
93<td align="left" valign="top"><p>It wasn't. <span class="bold"><strong>Boost.Thread</strong></span> was designed from scratch. Extensive
94                design discussions involved numerous people representing a wide range of
95                experience across many platforms. To ensure portability, the initial
96                implements were done in parallel using POSIX Threads and the Win32
97                threading API. But the <span class="bold"><strong>Boost.Thread</strong></span> design is very much in the spirit
98                of C++, and thus doesn't model such C based APIs.</p></td>
99</tr>
100<tr class="question">
101<td align="left" valign="top">
102<a name="id1746777"></a><a name="id1746780"></a><b>3.</b>
103</td>
104<td align="left" valign="top"><p>Why wasn't <span class="bold"><strong>Boost.Thread</strong></span> modeled after (specific library
105            name)?</p></td>
106</tr>
107<tr class="answer">
108<td align="left" valign="top"><b></b></td>
109<td align="left" valign="top"><p>Existing C++ libraries either seemed dangerous (often failing to
110                take advantage of prior art to reduce errors) or had excessive
111                dependencies on library components unrelated to threading. Existing C
112                libraries couldn't meet our C++ requirements, and were also missing
113                certain features. For instance, the WIN32 thread API lacks condition
114                variables, even though these are critical for the important Monitor
115                pattern [<span class="citation"><a href="../thread.html#thread.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>].</p></td>
116</tr>
117<tr class="question">
118<td align="left" valign="top">
119<a name="id1746819"></a><a name="id1746821"></a><b>4.</b>
120</td>
121<td align="left" valign="top"><p>Why do <a href="concepts.html#thread.concepts.mutexes" title="Mutexes">Mutexes</a>
122                have noncopyable semantics?</p></td>
123</tr>
124<tr class="answer">
125<td align="left" valign="top"><b></b></td>
126<td align="left" valign="top"><p>To ensure that <a href="../thread.html#thread.glossary.deadlock">deadlocks</a> don't occur. The
127                only logical form of copy would be to use some sort of shallow copy
128                semantics in which multiple mutex objects could refer to the same mutex
129                state. This means that if ObjA has a mutex object as part of its state
130                and ObjB is copy constructed from it, then when ObjB::foo() locks the
131                mutex it has effectively locked ObjA as well. This behavior can result
132                in deadlock. Other copy semantics result in similar problems (if you
133                think you can prove this to be wrong then supply us with an alternative
134                and we'll reconsider).</p></td>
135</tr>
136<tr class="question">
137<td align="left" valign="top">
138<a name="id1746850"></a><a name="id1746853"></a><b>5.</b>
139</td>
140<td align="left" valign="top"><p>How can you prevent <a href="../thread.html#thread.glossary.deadlock">deadlock</a> from occurring when
141                a thread must lock multiple mutexes?</p></td>
142</tr>
143<tr class="answer">
144<td align="left" valign="top"><b></b></td>
145<td align="left" valign="top"><p>Always lock them in the same order. One easy way of doing this is
146                to use each mutex's address to determine the order in which they are
147                locked. A future <span class="bold"><strong>Boost.Thread</strong></span> concept may wrap this pattern up in a
148                reusable class.</p></td>
149</tr>
150<tr class="question">
151<td align="left" valign="top">
152<a name="id1746885"></a><a name="id1746887"></a><b>6.</b>
153</td>
154<td align="left" valign="top"><p>Don't noncopyable <a href="concepts.html#thread.concepts.mutexes" title="Mutexes">Mutex</a> semantics mean that a
155                class with a mutex member will be noncopyable as well?</p></td>
156</tr>
157<tr class="answer">
158<td align="left" valign="top"><b></b></td>
159<td align="left" valign="top">
160<p>No, but what it does mean is that the compiler can't generate a
161                copy constructor and assignment operator, so they will have to be coded
162                explicitly. This is a <span class="bold"><strong>good thing</strong></span>,
163                however, since the compiler generated operations would not be <a href="../thread.html#thread.glossary.thread-safe">thread-safe</a>. The following
164                is a simple example of a class with copyable semantics and internal
165        synchronization through a mutex member.</p>
166<pre class="programlisting">
167class counter
168{
169public:
170   // Doesn't need synchronization since there can be no references to *this
171   // until after it's constructed!
172   explicit counter(int initial_value)
173      : m_value(initial_value)
174   {
175   }
176   // We only need to synchronize other for the same reason we don't have to
177   // synchronize on construction!
178   counter(const counter&amp; other)
179   {
180      boost::mutex::scoped_lock scoped_lock(other.m_mutex);
181      m_value = other.m_value;
182   }
183   // For assignment we need to synchronize both objects!
184   const counter&amp; operator=(const counter&amp; other)
185   {
186      if (this == &amp;other)
187         return *this;
188      boost::mutex::scoped_lock lock1(&amp;m_mutex &lt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
189      boost::mutex::scoped_lock lock2(&amp;m_mutex &gt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
190      m_value = other.m_value;
191      return *this;
192   }
193   int value() const
194   {
195      boost::mutex::scoped_lock scoped_lock(m_mutex);
196      return m_value;
197   }
198   int increment()
199   {
200      boost::mutex::scoped_lock scoped_lock(m_mutex);
201      return ++m_value;
202   }
203private:
204   mutable boost::mutex m_mutex;
205   int m_value;
206};
207</pre>
208</td>
209</tr>
210<tr class="question">
211<td align="left" valign="top">
212<a name="id1746934"></a><a name="id1746937"></a><b>7.</b>
213</td>
214<td align="left" valign="top"><p>How can you lock a <a href="concepts.html#thread.concepts.mutexes" title="Mutexes">Mutex</a> member in a const member
215                function, in order to implement the Monitor Pattern?</p></td>
216</tr>
217<tr class="answer">
218<td align="left" valign="top"><b></b></td>
219<td align="left" valign="top"><p>The Monitor Pattern [<span class="citation"><a href="../thread.html#thread.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>] mutex
220                should simply be declared as mutable. See the example code above. The
221                internal state of mutex types could have been made mutable, with all
222                lock calls made via const functions, but this does a poor job of
223                documenting the actual semantics (and in fact would be incorrect since
224                the logical state of a locked mutex clearly differs from the logical
225                state of an unlocked mutex). Declaring a mutex member as mutable clearly
226                documents the intended semantics.</p></td>
227</tr>
228<tr class="question">
229<td align="left" valign="top">
230<a name="id1746980"></a><a name="id1746982"></a><b>8.</b>
231</td>
232<td align="left" valign="top"><p>Why supply <code class="computeroutput"><a href="../boost/condition.html" title="Class condition">boost::condition</a></code> variables rather than
233                event variables?</p></td>
234</tr>
235<tr class="answer">
236<td align="left" valign="top"><b></b></td>
237<td align="left" valign="top"><p>Condition variables result in user code much less prone to <a href="../thread.html#thread.glossary.race-condition">race conditions</a> than
238                event variables. See <a href="rationale.html#thread.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> 
239                for analysis. Also see [<span class="citation"><a href="../thread.html#thread.bib.Hoare74">Hoare74</a></span>] and [<span class="citation"><a href="../thread.html#thread.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>].
240                </p></td>
241</tr>
242<tr class="question">
243<td align="left" valign="top">
244<a name="id1747046"></a><a name="id1747048"></a><b>9.</b>
245</td>
246<td align="left" valign="top"><p>Why isn't thread cancellation or termination provided?</p></td>
247</tr>
248<tr class="answer">
249<td align="left" valign="top"><b></b></td>
250<td align="left" valign="top"><p>There's a valid need for thread termination, so at some point
251                <span class="bold"><strong>Boost.Thread</strong></span> probably will include it, but only after we can find a
252                truly safe (and portable) mechanism for this concept.</p></td>
253</tr>
254<tr class="question">
255<td align="left" valign="top">
256<a name="id1747071"></a><a name="id1747073"></a><b>10.</b>
257</td>
258<td align="left" valign="top"><p>Is it safe for threads to share automatic storage duration (stack)
259                objects via pointers or references?</p></td>
260</tr>
261<tr class="answer">
262<td align="left" valign="top"><b></b></td>
263<td align="left" valign="top"><p>Only if you can guarantee that the lifetime of the stack object
264                will not end while other threads might still access the object. Thus the
265                safest practice is to avoid sharing stack objects, particularly in
266                designs where threads are created and destroyed dynamically. Restrict
267                sharing of stack objects to simple designs with very clear and
268                unchanging function and thread lifetimes. (Suggested by Darryl
269                Green).</p></td>
270</tr>
271<tr class="question">
272<td align="left" valign="top">
273<a name="id1747096"></a><a name="id1747098"></a><b>11.</b>
274</td>
275<td align="left" valign="top"><p>Why has class semaphore disappeared?</p></td>
276</tr>
277<tr class="answer">
278<td align="left" valign="top"><b></b></td>
279<td align="left" valign="top"><p>Semaphore was removed as too error prone. The same effect can be
280                achieved with greater safety by the combination of a mutex and a
281                condition variable.</p></td>
282</tr>
283<tr class="question">
284<td align="left" valign="top">
285<a name="id1747115"></a><a name="id1747117"></a><b>12.</b>
286</td>
287<td align="left" valign="top"><p>Why doesn't the thread's ctor take at least a void* to pass any
288            information along with the function? All other threading libs support
289            that and it makes Boost.Threads inferiour. </p></td>
290</tr>
291<tr class="answer">
292<td align="left" valign="top"><b></b></td>
293<td align="left" valign="top">
294<p>There is no need, because Boost.Threads are superiour! First
295            thing is that its ctor doesn't take a function but a functor. That
296            means that you can pass an object with an overloaded operator() and
297            include additional data as members in that object. Beware though that
298            this object is copied, use boost::ref to prevent that. Secondly, even
299            a boost::function&lt;void (void)&gt; can carry parameters, you only have to
300            use boost::bind() to create it from any function and bind its
301            parameters.</p>
302<p>That is also why Boost.Threads are superiour, because they
303            don't require you to pass a type-unsafe void pointer. Rather, you can
304            use the flexible Boost.Functions to create a thread entry out of
305            anything that can be called.</p>
306</td>
307</tr>
308</tbody>
309</table>
310</div>
311</div>
312<table width="100%"><tr>
313<td align="left"><small><p>Last revised: April 24, 2007 at 16:11:17 GMT</p></small></td>
314<td align="right"><small>Copyright © 2001-2003 William E. Kempf</small></td>
315</tr></table>
316<hr>
317<div class="spirit-nav">
318<a accesskey="p" href="../boost/xtime.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../thread.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="configuration.html"><img src="../images/next.png" alt="Next"></a>
319</div>
320</body>
321</html>
Note: See TracBrowser for help on using the repository browser.