|
Boost.ThreadsOverview |
Introduction
Dangers
C++ Standard Library usage
Common requirements
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. Definitions gives a more complete description of the multi-threading execution environment.
Multi-threading provides several advantages:
Beyond the errors which can occur in single-threaded programs, multi-threaded programs are subject to additional errors:
Every multi-threaded program must be designed carefully to avoid race conditions and deadlock. These aren'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.
The Boost.Threads design attempts to minimize these errors, but they will still occur unless the programmer proactively designs to avoid them.
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:
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.
Design patterns for reliable multi-threaded programs, including the important monitor pattern, are presented in Pattern-Oriented Software Architecture Volume 2 - Patterns for Concurrent and Networked Objects [Schmidt 00]. Many important multi-threading programming considerations (independent of threading library) are discussed in Programming with POSIX Threads [Butenhof 97].
Doing some reading before attempting multi-threaded designs will give you a head start toward reliable multi-threaded programs.
Warning: Multi-threaded programs such as those using Boost.Threads must link to thread-safe versions of all runtime libraries used by the program, including the runtime library for the C++ Standard Library. Otherwise race conditions will occur when multiple threads simultaneously execute runtime library functions for new, delete, or other language features which imply shared state.
Certain C++ Standard Library functions inherited from C are particular problems because they hold internal state between calls:
It is possible to write thread-safe implementations of these by using thread-specific storage, and several C++ compiler vendors do just that. The technique is well-know and is explained in [Buttenhof-97].
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.
Recommendation: For the most portable, yet thread-safe code, use Boost replacements for the problem functions. See the Boost Random Number Library and Boost Tokenizer Library.
Boost.Threads destructors never throw exceptions. Unless otherwise specified, other Boost.Threads functions that do not have an exception-specification may throw implementation-defined exceptions.
In particular, Boost.Threads 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 boost::thread_resource_error, and certain lock related failures by throwing an exception of type boost::lock_error
Rationale: Follows the C++ Standard Library practice of allowing all functions except destructors or other specified functions to throw exceptions on errors.
Boost.Threads 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 boost::noncopyable. Users should not depend on this derivation, however, as implementations are free to meet the NonCopyable requirement in other ways.
Revised 05 November, 2001
© Copyright 2001 Beman Dawes