mirror of
https://github.com/boostorg/thread.git
synced 2026-01-22 17:52:18 +00:00
175 lines
7.1 KiB
HTML
175 lines
7.1 KiB
HTML
<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 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, POSIX threads doesn't support a maximum value for semaphores.
|
|
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>
|
|
|
|
<hr>
|
|
|
|
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->04 September, 2001<!--webbot bot="Timestamp" endspan i-checksum="39335" -->
|
|
</p>
|
|
|
|
<p><i>© Copyright <a href="mailto:williamkempf@hotmail.com">William E. Kempf</a>
|
|
2001 all rights reserved.</i></p>
|
|
|
|
</body>
|
|
</html>
|