2
0
mirror of https://github.com/boostorg/thread.git synced 2026-01-27 07:22:11 +00:00
Files
thread/doc/overview.html
2002-02-11 23:13:04 +00:00

175 lines
9.5 KiB
HTML

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" type="text/css" href="../../../boost.css">
<title>Boost.Threads - Overview</title>
</head>
<body link="#0000ff" vlink="#800080">
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
"header">
<tr>
<td valign="top" width="300">
<h3><a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../c++boost.gif" border="0"></a></h3>
</td>
<td valign="top">
<h1 align="center">Boost.Threads</h1>
<h2 align="center">Overview</h2>
</td>
</tr>
</table>
<hr>
<dl class="index">
<dt><a href="#introduction">Introduction</a></dt>
<dt><a href="#dangers">Dangers</a></dt>
<dl class="index">
<dt><a href="#testing-debugging">Testing and debugging considerations</a></dt>
<dt><a href="#head-start">Getting a head start</a></dt>
</dl>
<dt><a href="#library">C++ Standard Library usage in multi-threaded programs</a></dt>
<dl class="index">
<dt><a href="#runtime-libraries">Runtime libraries</a></dt>
<dt><a href="#non-thread-safe-functions">Potentially non-thread-safe functions</a></dt>
</dl>
<dt><a href="#common-requirements">Common requirements for all Boost.Threads components</a></dt>
<dl class="index">
<dt><a href="#exceptions">Exceptions</a></dt>
<dt><a href="#non-copyable">NonCopyable requirement</a></dt>
</dl>
</dl>
<h2><a name="introduction"></a>Introduction</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"></a>Dangers</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><a name="testing-debugging"></a>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><a name="head-start"></a>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"></a>C++ Standard Library usage in multi-threaded programs</h2>
<h3><a name="runtime-libraries"></a>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><a name="non-thread-safe-functions"></a>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-requirements"></a>Common requirements for all Boost.Threads components</h2>
<h3><a name="exceptions"></a>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="non-copyable"></a>NonCopyable 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><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
All Rights Reserved.</i></p>
<p>Permission to use, copy, modify, distribute and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice appear in all copies and that both that copyright notice
and this permission notice appear in supporting documentation. William E. Kempf
makes no representations about the suitability of this software for any purpose.
It is provided &quot;as is&quot; without express or implied warranty.</p>
</body>
</html>