mirror of
https://github.com/boostorg/thread.git
synced 2026-01-22 17:52:18 +00:00
174 lines
9.6 KiB
HTML
174 lines
9.6 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 multithreaded 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 multithreaded programs to distinguish them from traditional single-threaded
|
|
programs. <a href="definitions.html">Definitions</a> gives a more complete description
|
|
of the multithreading execution environment.</p>
|
|
<p>Multithreading 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.
|
|
Multithreading is usually an absolute requirement for these programs.</li>
|
|
</ul>
|
|
<ul>
|
|
<li>Well-designed multithreaded programs may execute faster than single-threaded
|
|
programs, particularly on multiprocessor hardware. Note, however, that poorly-designed
|
|
multithreaded programs are often slower that single-threaded programs.</li>
|
|
</ul>
|
|
<ul>
|
|
<li>Some program designs may be easier to formulate using a multithreaded 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, multithreaded
|
|
programs are subject to additional errors:</p>
|
|
<ul>
|
|
<li><a href="definitions.html#definition-race-condition">Race conditions</a>.</li>
|
|
<li><a href="definitions.html#definition-deadlock">Deadlock</a> (sometimes called
|
|
"deadly embrace")</li>
|
|
<li><a href="definitions.html#definition-priority-failure">Priority failures</a>
|
|
(priority inversion, infinite overtaking, starvation, etc.)</li>
|
|
</ul>
|
|
<p>Every multithreaded program must be designed carefully to avoid race conditions,
|
|
priority failures and deadlock. These aren't rare or exotic failures - they
|
|
are virtually guaranteed to occur unless multithreaded code is designed to avoid
|
|
them. Priority failures are somewhat less common, but are nonetheless 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>Multithreaded 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'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 multithreaded programs are inherently unreliable,
|
|
many reliable multithreaded programs do exist. Multithreading techniques are
|
|
known which lead to reliable programs.</p>
|
|
<p>Design patterns for reliable multithreaded 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 multithreading
|
|
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 multithreaded designs will give you a
|
|
head start toward reliable multithreaded programs.</p>
|
|
<h2><a name="library"></a>C++ Standard Library usage in multithreaded programs</h2>
|
|
<h3><a name="runtime-libraries"></a>Runtime libraries</h3>
|
|
<p><b>Warning:</b> Multithreaded 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="tss.html#class-thread_specific_ptr">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-gaurantees"></a>Common guarantees 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="exceptions.html#class-thread_resource_error">boost::thread_resource_error</a>,
|
|
and certain lock related failures by throwing an exception of type <a href="exceptions.html#class-lock_error">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>© 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 "as is" without express or implied warranty.</p>
|
|
</body>
|
|
</html>
|