2
0
mirror of https://github.com/boostorg/thread.git synced 2026-01-22 05:42:37 +00:00
Files
thread/doc/overview.html
Beman Dawes 2719c4d545 Try to get the date stamps in sync
[SVN r11618]
2001-11-07 00:37:59 +00:00

225 lines
9.4 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 summary="header" 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 called 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. 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.
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!</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>
<li><a href="definitions.html#Deadlock">Deadlock</a> (sometimes
called &quot;deadly embrace&quot;)</li>
<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. These aren&#39;t rare or exotic failures
- they are virtually guaranteed to occur unless multi-threaded code is
designed to avoid them. 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. That can make testing and debugging a
nightmare:</p>
<ul>
<li>Failures are often not repeatable.</li>
<li>Probe effect causes debuggers to produce very different results
from non-debug uses.</li>
<li>Debuggers require special support to show thread state.</li>
<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.</li>
<li>For programs which create a varying number of threads according
to workload, tests which don&#39;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>]. 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>Doing some reading before attempting multi-threaded designs will give
you a head start toward 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.</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</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. 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. 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. 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 -->05 November, 2001<!--webbot bot="Timestamp" endspan i-checksum="39359" --></p>
<p>&copy; Copyright 2001 Beman Dawes</p>
</body>
</html>