Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_33_1/doc/html/threads/faq.html @ 12

Last change on this file since 12 was 12, checked in by landauf, 18 years ago

added boost
File size: 13.9 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.69.1">
7<link rel="start" href="../index.html" title="The Boost C++ Libraries">
8<link rel="up" href="../threads.html" title="Chapter 12. Boost.Threads">
9<link rel="prev" href="../xtime.html" title="Struct xtime">
10<link rel="next" href="../thread/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.png (6897 bytes)" 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="../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>
24</div>
25<div class="section" lang="en">
26<div class="titlepage"><div><div><h3 class="title">
27<a name="threads.faq"></a>Frequently Asked Questions</h3></div></div></div>
28<div class="qandaset">
29<dl>
30<dt>1. <a href="faq.html#id2786577">Are lock objects thread safe?</a>
31</dt>
32<dt>2. <a href="faq.html#id2786619">Why was Boost.Threads modeled after (specific library
33                name)?</a>
34</dt>
35<dt>3. <a href="faq.html#id2786652">Why wasn't Boost.Threads modeled after (specific library
36            name)?</a>
37</dt>
38<dt>4. <a href="faq.html#id2786688">Why do Mutexes
39                have noncopyable semantics?</a>
40</dt>
41<dt>5. <a href="faq.html#id2786718">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#id2786744">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#id2786812">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#id2786850">Why supply boost::condition variables rather than
51                event variables?</a>
52</dt>
53<dt>9. <a href="faq.html#id2786907">Why isn't thread cancellation or termination provided?</a>
54</dt>
55<dt>10. <a href="faq.html#id2786924">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#id2786940">Why has class semaphore disappeared?</a>
59</dt>
60</dl>
61<table border="0" summary="Q and A Set">
62<col align="left" width="1%">
63<tbody>
64<tr class="question">
65<td align="left" valign="top">
66<a name="id2786577"></a><a name="id2786578"></a><b>1.</b>
67</td>
68<td align="left" valign="top"><p>Are lock objects <a href="../threads.html#threads.glossary.thread-safe">thread safe</a>?</p></td>
69</tr>
70<tr class="answer">
71<td align="left" valign="top"><b></b></td>
72<td align="left" valign="top"><p><span class="bold"><strong>No!</strong></span> Lock objects are not meant to
73                be shared between threads. They are meant to be short-lived objects
74                created on automatic storage within a code block. Any other usage is
75                just likely to lead to errors and won't really be of actual benefit anyway.
76                Share <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutexes</a>, not
77                Locks. For more information see the <a href="rationale.html#threads.rationale.locks" title="Rationale for the Lock Design">rationale</a> behind the
78                design for lock objects.</p></td>
79</tr>
80<tr class="question">
81<td align="left" valign="top">
82<a name="id2786619"></a><a name="id2786620"></a><b>2.</b>
83</td>
84<td align="left" valign="top"><p>Why was <span class="bold"><strong>Boost.Threads</strong></span> modeled after (specific library
85                name)?</p></td>
86</tr>
87<tr class="answer">
88<td align="left" valign="top"><b></b></td>
89<td align="left" valign="top"><p>It wasn't. <span class="bold"><strong>Boost.Threads</strong></span> was designed from scratch. Extensive
90                design discussions involved numerous people representing a wide range of
91                experience across many platforms. To ensure portability, the initial
92                implements were done in parallel using POSIX Threads and the Win32
93                threading API. But the <span class="bold"><strong>Boost.Threads</strong></span> design is very much in the spirit
94                of C++, and thus doesn't model such C based APIs.</p></td>
95</tr>
96<tr class="question">
97<td align="left" valign="top">
98<a name="id2786652"></a><a name="id2786653"></a><b>3.</b>
99</td>
100<td align="left" valign="top"><p>Why wasn't <span class="bold"><strong>Boost.Threads</strong></span> modeled after (specific library
101            name)?</p></td>
102</tr>
103<tr class="answer">
104<td align="left" valign="top"><b></b></td>
105<td align="left" valign="top"><p>Existing C++ libraries either seemed dangerous (often failing to
106                take advantage of prior art to reduce errors) or had excessive
107                dependencies on library components unrelated to threading. Existing C
108                libraries couldn't meet our C++ requirements, and were also missing
109                certain features. For instance, the WIN32 thread API lacks condition
110                variables, even though these are critical for the important Monitor
111                pattern [<span class="citation"><a href="../threads.html#threads.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>].</p></td>
112</tr>
113<tr class="question">
114<td align="left" valign="top">
115<a name="id2786688"></a><a name="id2786689"></a><b>4.</b>
116</td>
117<td align="left" valign="top"><p>Why do <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutexes</a>
118                have noncopyable semantics?</p></td>
119</tr>
120<tr class="answer">
121<td align="left" valign="top"><b></b></td>
122<td align="left" valign="top"><p>To ensure that <a href="../threads.html#threads.glossary.deadlock">deadlocks</a> don't occur. The
123                only logical form of copy would be to use some sort of shallow copy
124                semantics in which multiple mutex objects could refer to the same mutex
125                state. This means that if ObjA has a mutex object as part of its state
126                and ObjB is copy constructed from it, then when ObjB::foo() locks the
127                mutex it has effectively locked ObjA as well. This behavior can result
128                in deadlock. Other copy semantics result in similar problems (if you
129                think you can prove this to be wrong then supply us with an alternative
130                and we'll reconsider).</p></td>
131</tr>
132<tr class="question">
133<td align="left" valign="top">
134<a name="id2786718"></a><a name="id2786720"></a><b>5.</b>
135</td>
136<td align="left" valign="top"><p>How can you prevent <a href="../threads.html#threads.glossary.deadlock">deadlock</a> from occurring when
137                a thread must lock multiple mutexes?</p></td>
138</tr>
139<tr class="answer">
140<td align="left" valign="top"><b></b></td>
141<td align="left" valign="top"><p>Always lock them in the same order. One easy way of doing this is
142                to use each mutex's address to determine the order in which they are
143                locked. A future <span class="bold"><strong>Boost.Threads</strong></span> concept may wrap this pattern up in a
144                reusable class.</p></td>
145</tr>
146<tr class="question">
147<td align="left" valign="top">
148<a name="id2786744"></a><a name="id2786745"></a><b>6.</b>
149</td>
150<td align="left" valign="top"><p>Don't noncopyable <a href="concepts.html#threads.concepts.mutexes" title="Mutexes">Mutex</a> semantics mean that a
151                class with a mutex member will be noncopyable as well?</p></td>
152</tr>
153<tr class="answer">
154<td align="left" valign="top"><b></b></td>
155<td align="left" valign="top">
156<p>No, but what it does mean is that the compiler can't generate a
157                copy constructor and assignment operator, so they will have to be coded
158                explicitly. This is a <span class="bold"><strong>good thing</strong></span>,
159                however, since the compiler generated operations would not be <a href="../threads.html#threads.glossary.thread-safe">thread-safe</a>. The following
160                is a simple example of a class with copyable semantics and internal
161        synchronization through a mutex member.</p>
162<pre class="programlisting">
163class counter
164{
165public:
166   // Doesn't need synchronization since there can be no references to *this
167   // until after it's constructed!
168   explicit counter(int initial_value)
169      : m_value(initial_value)
170   {
171   }
172   // We only need to synchronize other for the same reason we don't have to
173   // synchronize on construction!
174   counter(const counter&amp; other)
175   {
176      boost::mutex::scoped_lock scoped_lock(other.m_mutex);
177      m_value = other.m_value;
178   }
179   // For assignment we need to synchronize both objects!
180   const counter&amp; operator=(const counter&amp; other)
181   {
182      if (this == &amp;other)
183         return *this;
184      boost::mutex::scoped_lock lock1(&amp;m_mutex &lt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
185      boost::mutex::scoped_lock lock2(&amp;m_mutex &gt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
186      m_value = other.m_value;
187      return *this;
188   }
189   int value() const
190   {
191      boost::mutex::scoped_lock scoped_lock(m_mutex);
192      return m_value;
193   }
194   int increment()
195   {
196      boost::mutex::scoped_lock scoped_lock(m_mutex);
197      return ++m_value;
198   }
199private:
200   mutable boost::mutex m_mutex;
201   int m_value;
202};
203</pre>
204</td>
205</tr>
206<tr class="question">
207<td align="left" valign="top">
208<a name="id2786812"></a><a name="id2786813"></a><b>7.</b>
209</td>
210<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
211                function, in order to implement the Monitor Pattern?</p></td>
212</tr>
213<tr class="answer">
214<td align="left" valign="top"><b></b></td>
215<td align="left" valign="top"><p>The Monitor Pattern [<span class="citation"><a href="../threads.html#threads.bib.SchmidtStalRohnertBuschmann">SchmidtStalRohnertBuschmann</a></span>] mutex
216                should simply be declared as mutable. See the example code above. The
217                internal state of mutex types could have been made mutable, with all
218                lock calls made via const functions, but this does a poor job of
219                documenting the actual semantics (and in fact would be incorrect since
220                the logical state of a locked mutex clearly differs from the logical
221                state of an unlocked mutex). Declaring a mutex member as mutable clearly
222                documents the intended semantics.</p></td>
223</tr>
224<tr class="question">
225<td align="left" valign="top">
226<a name="id2786850"></a><a name="id2786851"></a><b>8.</b>
227</td>
228<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
229                event variables?</p></td>
230</tr>
231<tr class="answer">
232<td align="left" valign="top"><b></b></td>
233<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
234                event variables. See <a href="rationale.html#threads.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> 
235                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>].
236                </p></td>
237</tr>
238<tr class="question">
239<td align="left" valign="top">
240<a name="id2786907"></a><a name="id2786908"></a><b>9.</b>
241</td>
242<td align="left" valign="top"><p>Why isn't thread cancellation or termination provided?</p></td>
243</tr>
244<tr class="answer">
245<td align="left" valign="top"><b></b></td>
246<td align="left" valign="top"><p>There's a valid need for thread termination, so at some point
247                <span class="bold"><strong>Boost.Threads</strong></span> probably will include it, but only after we can find a
248                truly safe (and portable) mechanism for this concept.</p></td>
249</tr>
250<tr class="question">
251<td align="left" valign="top">
252<a name="id2786924"></a><a name="id2786925"></a><b>10.</b>
253</td>
254<td align="left" valign="top"><p>Is it safe for threads to share automatic storage duration (stack)
255                objects via pointers or references?</p></td>
256</tr>
257<tr class="answer">
258<td align="left" valign="top"><b></b></td>
259<td align="left" valign="top"><p>Only if you can guarantee that the lifetime of the stack object
260                will not end while other threads might still access the object. Thus the
261                safest practice is to avoid sharing stack objects, particularly in
262                designs where threads are created and destroyed dynamically. Restrict
263                sharing of stack objects to simple designs with very clear and
264                unchanging function and thread lifetimes. (Suggested by Darryl
265                Green).</p></td>
266</tr>
267<tr class="question">
268<td align="left" valign="top">
269<a name="id2786940"></a><a name="id2786941"></a><b>11.</b>
270</td>
271<td align="left" valign="top"><p>Why has class semaphore disappeared?</p></td>
272</tr>
273<tr class="answer">
274<td align="left" valign="top"><b></b></td>
275<td align="left" valign="top"><p>Semaphore was removed as too error prone. The same effect can be
276                achieved with greater safety by the combination of a mutex and a
277                condition variable.</p></td>
278</tr>
279</tbody>
280</table>
281</div>
282</div>
283<table width="100%"><tr>
284<td align="left"><small><p>Last revised: July 17, 2004 at 04:33:59 GMT</p></small></td>
285<td align="right"><small>Copyright © 2001-2003 William E. Kempf</small></td>
286</tr></table>
287<hr>
288<div class="spirit-nav">
289<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>
290</div>
291</body>
292</html>
Note: See TracBrowser for help on using the repository browser.