boost/thread
2
0
Fork 0
mirror of https://github.com/boostorg/thread.git synced 2026-01-27 07:22:11 +00:00
Code Issues Projects Releases Wiki Activity

Added a FAQ document.

Browse Source 
[SVN r10549]
This commit is contained in:
William E. Kempf
2001-07-06 18:02:56 +00:00
parent c2930faaec
commit 6e83cfdc72
3 changed files with 55 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
doc/faq.html Normal file
View File

@@ -0,0 +1,50 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="keywords" content="threads, BTL, thread library, C++">
<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>Are lock objects thread safe?</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
mutexes, not locks. For more information on this see the documentation on the
<a href="rationale.html#lock_objects">rationale</a> behind the design for lock objects.</p>
<h2>Why was Boost.Threads modelled after the (platform specific library name)
library?</h2>
<p>It wasn't. As the developer I tried very hard to not let my own biases show in the
development of this library. Each library has its own strengths and weaknesses and I wanted
to avoid the mistakes made by others (though I'm sure I made plenty of my own). For instance,
inclusion of a max value for semaphores seemed like a smart decision despite the lack of support
for this concept in POSIX. On the other hand, lack of a condition variable concept in the
Windows API was a big mistake since it's the only way to model a monitor pattern. If you think
you see a bias for any platform/library, you're probably wrong.</p>
<hr>
<p><i>Copyright <a href="mailto:williamkempf@hotmail.com">William E. Kempf</a>
2001 all rights reserved.</i></p>
</body>
</html>

1
doc/index.html
View File

@@ -48,6 +48,7 @@
<li><a href="thread_formal_definition.html">Formal definition of
&quot;Thread&quot;</a></li>
<li><a href="rationale.html">Rationale for design decisions</a></li>
<li><a href="faq.html">Frequently Asked Questions</a></li>
</ul>
<hr>

8
doc/rationale.html
View File

@@ -28,7 +28,7 @@ design as well as prevent future rehashing of discussions and thought processes
already occured. It can also give users a lot of insight into the design process required
for this library.</p>
<h2>Rationale for the Creation of Boost.Threads</h2>
<h2><a name="library">Rationale for the Creation of Boost.Threads</a></h2>
<p>Processes often have a degree of "potential parallelism" and it can often be more intuitive
to design systems with this in mind. Further, these parallel processes can result in more responsive
@@ -53,7 +53,7 @@ for writing multi-threaded programs on numerous platforms. There's a hope that
be the basis for a more detailed proposal for the C++ standards committee to consider for inclusion
in the next C++ standard.</p>
<h2>Rationale for the Low Level Primitives Supported in Boost.Threads</h2>
<h2><a name="primitives">Rationale for the Low Level Primitives Supported in Boost.Threads</a></h2>
<p>The Boost.Threads library supplies a set of low level primitives for writing multi-threaded
programs, such as semaphores, mutexes and condition variables. In fact, the first release of
@@ -75,7 +75,7 @@ useful in and of themselves, even if it's hard to prove that their usage is corr
many users will be familiar with these lower level concepts but be unfamiliar with any of the
higher level concepts there's also an argument for accessibility.</p>
<h2>Rationale for the Lock Design</h2>
<h2><a name="lock_objects">Rationale for the Lock Design</a></h2>
<p>Programmers who are used to multi-threaded programming issues will quickly note that the
Boost.Thread's design for mutex lock concepts is not thread safe (this is clearly documented
@@ -105,7 +105,7 @@ safe. Instead, sharing a lock object between threads results in undefined behav
only proper usage of lock objects is within block scope this isn't a problem, and so long
as the lock object is properly used there's no danger of any multi-threading issues.</p>
<h2>Rationale for Non-copyable Thread Type</h2>
<h2><a name="thread">Rationale for Non-copyable Thread Type</a></h2>
<p>Programmers who are used to C libraries for multi-threaded programming are likely to
wonder why Boost.Threads uses a non-copyable design for boost::thread. After all, the C