diff options
Diffstat (limited to 'doc/html/threads/faq.html')
| -rw-r--r-- | doc/html/threads/faq.html | 292 |
1 files changed, 292 insertions, 0 deletions
diff --git a/doc/html/threads/faq.html b/doc/html/threads/faq.html new file mode 100644 index 0000000000..3f1af657e1 --- /dev/null +++ b/doc/html/threads/faq.html @@ -0,0 +1,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> |