2
0
mirror of https://github.com/boostorg/thread.git synced 2026-01-22 17:52:18 +00:00
Files
thread/doc/overview.html
Beman Dawes 25fd0f52e7 Initial commit
[SVN r11102]
2001-09-12 14:36:32 +00:00

157 lines
8.0 KiB
HTML

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Boost.Threads Overview</title>
</head>
<body>
<table border="0" cellpadding="7" cellspacing="0" width="100%">
<tr>
<td valign="top" width="300">
<h3><IMG height=86 alt="C++ Boost" src="../../../c++boost.gif" width=277></h3>
</td>
<td valign="top">
<h1 align="center">Boost.Threads</h1>
<h2 align="center">Overview</h2>
</td>
</tr>
</table>
<p><a href="#Introduction">Introduction</a><br>
<a href="#Dangers">Dangers</a><br>
<a href="#Library">C++ Standard Library usage</a><br>
<a href="#Common">Common requirements</a></p>
<h2><a name="Introduction">Introduction</a></h2>
<p>Boost.Threads allows C++ programs to execute as multiple, asynchronous,
independent, threads-of-execution. Each thread has its own machine state
including program instruction counter and registers. Programs which execute as
multiple threads are call multi-threaded programs to distinguish them from
traditional single-threaded programs. <a href="definitions.html">Definitions</a>
gives a more complete description of the multi-threading execution environment.</p>
<p>Multi-threading provides several advantages:</p>
<ul>
<li>Programs which would otherwise block waiting for some external event can
continue to respond if the blocking operation is placed in a separate
thread.&nbsp; Multi-threading is usually an absolute requirement for these
programs.</li>
</ul>
<ul>
<li>Well-designed multi-threaded programs may execute faster than single-threaded
programs, particularly on multi-processor hardware.&nbsp;
Note, however, that poorly-designed multi-threaded programs are often slower
that single-threaded programs.</li>
</ul>
<ul>
<li>Some program designs may be easier to formulate using a multi-threaded
approach.
After all, the real world is asynchronous!&nbsp;</li>
</ul>
<h2><a name="Dangers">Dangers</a></h2>
<p>Beyond the errors which can occur in single-threaded programs, multi-threaded
programs are subject to additional errors:</p>
<ul>
<li><a href="definitions.html#Race condition">Race conditions</a>.
<li><a href="definitions.html#Deadlock">Deadlock</a> (sometimes called
&quot;deadly embrace&quot;)
<li><a href="definitions.html#Priority failure">Priority failures</a>
(priority inversion, infinite overtaking, starvation, etc.)</li>
</ul>
<p>Every multi-threaded program must be designed carefully to avoid race
conditions and deadlock.&nbsp; These aren't rare or exotic failures - they are
virtually guaranteed to occur unless multi-threaded code is designed to avoid
them.&nbsp; Priority failures are somewhat less common, but are none-the-less
serious.</p>
<p>The <a href="introduction.html">Boost.Threads design</a> attempts to minimize
these errors, but they will still occur unless the programmer proactively
designs to avoid them.</p>
<h3>Testing and debugging considerations</h3>
<p>Multi-threaded programs are non-deterministic. In other words, the same
program with the same input data may follow different execution paths each time
it is invoked.&nbsp; That can make testing and debugging a nightmare:</p>
<ul>
<li>Failures are often not repeatable.
<li>Probe effect causes debuggers to produce very different results from
non-debug uses.
<li>Debuggers require special support to show thread state.
<li>Tests on a single processor system may give no indication of serious
errors which would appear on multiprocessor systems, and visa versa. Thus test
cases should include a varying number of processors.&nbsp;</li>
<li>For programs which create a varying number of threads according to
workload, tests which don't span the full range of possibilities may miss
serious errors.</li>
</ul>
<h3>Getting a head start</h3>
<p>Although it might appear that multi-threaded programs are inherently
unreliable, many reliable multi-threaded programs do exist. Multi-threading
techniques are known which lead to reliable programs.</p>
<p>Design patterns for reliable multi-threaded programs, including the important
<i>monitor</i> pattern, are presented in <cite>Pattern-Oriented Software Architecture Volume 2 - Patterns for
Concurrent and Networked Objects</cite> [<a href="bibliography.html#Schmidt-00">Schmidt
00</a>].&nbsp; Many important multi-threading programming considerations
(independent of threading library) are discussed in <cite>Programming with
POSIX Threads</cite> [<a href="bibliography.html#Butenhof-97">Butenhof 97</a>].</p>
<p>Reading and study first yields a head start toward designing reliable
multi-threaded programs.</p>
<h2><a name="Library">C++ Standard Library usage in multi-threaded programs</a></h2>
<h3>Runtime libraries</h3>
<p><b>Warning:</b> Multi-threaded programs such as those using <b>Boost.Threads</b> must link to
<a href="definitions.html#Thread-safe">thread-safe</a> versions of all runtime
libraries used by the program, including the runtime library for the C++
Standard Library. Otherwise <a href="definitions.html#Race condition">race
conditions</a> will occur when multiple threads simultaneously execute runtime
library functions for <i>new</i>, <i>delete</i>, or other language features
which imply shared state.&nbsp;&nbsp;</p>
<h3>Potentially non-thread-safe functions</h3>
<p>Certain C++ Standard Library functions inherited from C are particular
problems because they hold internal state between calls:</p>
<ul>
<li>rand</li>
<li>strtok</li>
<li>asctime</li>
<li>ctime&nbsp;</li>
<li>gmtime</li>
<li>localtime</li>
</ul>
<p>It is possible to write thread-safe implementations of these by using <a href="thread_specific_ptr.html">thread-specific
storage</a>, and several C++ compiler vendors do just that.&nbsp; The technique
is well-know and is explained in [<a href="bibliography.html#Butenhof-97">Buttenhof-97</a>].</p>
<p>But at least one vendor (HP-UX) does not provide thread-safe implementations
of the above functions in their otherwise thread-safe runtime library.&nbsp;
Instead they provide replacement functions with different names and arguments.</p>
<p><b>Recommendation:</b> For the most portable, yet thread-safe code, use Boost
replacements for the problem functions.&nbsp; See the <a href="../../random/index.html">Boost
Random Number Library</a> and <a href="../../tokenizer/index.htm">Boost
Tokenizer Library</a>.</p>
<h2><a name="Common">Common</a> requirements for all Boost.Threads components</h2>
<h3>Exceptions</h3>
<p> <b>Boost.Threads</b> destructors never throw exceptions. Unless otherwise
specified, other <b>Boost.Threads</b>
functions that do not have an exception-specification may throw implementation-defined exceptions.</p>
<p>In particular, <b>Boost.Threads</b> reports failure to allocate storage by throwing an exception of type
std::bad_alloc, or a class derived from std::bad_alloc, failure to obtain
thread resources other than memory by throwing an exception of type <a href="thread_resource_error.html">boost::thread_resource_error</a>,
and certain lock related failures by throwing an exception of type <a href="lock_error.html">boost::lock_error</a></p>
<p><b>Rationale: </b>Follows the C++ Standard Library practice of allowing all
functions except destructors or other specified functions to throw exceptions on
errors.</p>
<h3><a name="NonCopyable">NonCopyable</a> requirement</h3>
<p><b>Boost.Threads</b> classes documented as meeting the NonCopyable requirement disallow copy
construction and copy assignment. For the sake of exposition, the synopsis of
such classes show private derivation from <a href="../../utility/utility.htm">boost::noncopyable</a>.
Users should not depend on this derivation, however, as implementations are free
to meet the NonCopyable requirement in other ways.</p>
<hr>
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->12 September, 2001<!--webbot bot="Timestamp" endspan i-checksum="39332" -->
</p>
<p>© Copyright 2001 Beman Dawes</p>
</body>
</html>