Boost
C++ Libraries
...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
Boost
C++ Libraries
...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
|
|
Boost.ThreadsIntroduction to Design |
With client/server and three-tier architectures becoming common place in today's world, it's becoming increasingly important for programs to be able to handle parallel processing. Modern day operating systems usually provide some support for this through native thread APIs. Unfortunately, writing portable code that makes use of parallel processing in C++ is made very difficult by a lack of a standard interface for these native APIs. Further, these APIs are almost universally C APIs and fail to take advantage of C++'s strengths, or to address C++'s issues.
The Boost.Threads library is an attempt to define a portable interface for writing parallel processes in C++.
The Boost.Threads library has several goals that should help to set it apart from other solutions. These goals are listed in order of precedence with full descriptions below.
Boost.Threads was designed to be highly portable. The goal is for the interface to be easily implemented on any platform that supports threads, and possibly even on platforms without native thread support.
Boost.Threads was designed to be as safe as possible. Writing thread-safe code is very difficult and successful libraries must strive to insulate the programmer from dangerous constructs as much as possible. This is accomplished in several ways:
C++ language features are used make correct usage easy (if possible, the default) and error-prone impossible or at least more difficult. For example, see the Mutex and Lock designs, and how note how they interact.
Certain traditional concurrent programming features are considered so error-prone that they are not provided at all. For example, see the Events Not Provided rationale.
Dangerous features, or features which may be misused, are identified as such in the documentation to make users aware of potential pitfalls.
Boost.Threads was designed to be flexible. This goal is often at odds with safety. When functionality might be compromised by the desire to keep the interface safe, Boost.Threads has been designed to provide the functionality, but to make it's use prohibitive for general use. In other words, the interfaces have been designed such that it's usually obvious when something is unsafe, and the documentation is written to explain why.
Boost.Threads was designed to be as efficient as possible. When building a library on top of another library there is always a danger that the result will be so much slower than the "native" API that programmers are inclined to ignore the higher level API. Boost.Threads was designed to minimize the chances of this occurring. The interfaces have been crafted to allow an implementation the greatest chance of being as efficient as possible. This goal is often at odds with the goal for safety. Every effort was made to ensure efficient implementations, but when in conflict safety has always taken precedence.
Another goal of Boost.Threads was to take a dynamic, iterative approach in its development. The computing industry is still exploring the concepts of parallel programming. Most thread libraries supply only simple primitive concepts for thread synchronization. These concepts are very simple, but they are very difficult to use safely or to provide formal proofs for constructs built on top of them. There has been a lot of research in other concepts, such as in "Communicating Sequential Processes." Boost.Threads was designed in iterative steps, providing the building blocks necessary for the next step, and giving the researcher the tools necessary to explore new concepts in a portable manner.
Given the goal of following a dynamic, iterative approach Boost.Threads shall go through several growth cycles. Each phase in its development shall be roughly documented here.
Boost is all about providing high quality libraries with implementations for many platforms. Unfortunately, there's a big problem faced by developers wishing to supply such high quality libraries, namely thread-safety. The C++ standard doesn't address threads at all, but real world programs often make use of native threading support. A portable library that doesn't address the issue of thread-safety is there for not much help to a programmer who wants to use the library in his multithreaded application. So there's a very great need for portable primitives that will allow the library developer to create thread-safe implementations. This need far out weighs the need for portable methods to create and manage threads.
Because of this need, the first phase of Boost.Threads focuses solely on providing portable primitive concepts for thread synchronization. Types provided in this phase include the mutex/try_mutex/timed_mutex, recursive_mutex/recursive_try_mutex/recursive_timed_mutex and lock_error. These are considered the "core" synchronization primitives, though there are others that will be added in later phases.
This phase addresses the creation and management of threads and provides a mechanism for thread specific storage (data associated with a thread instance). Thread management is a tricky issue in C++, so this phase addresses only the basic needs of multithreaded program. Later phases are likely to add additional functionality in this area. This phase of Boost.Threads adds the thread and thread_specific_ptr types. With these additions the Boost.Threads library can be considered minimal but complete.
The next phase will address more advanced synchronization concepts, such as read/write mutexes and barriers.
Revised 05 November, 2001
© Copyright William E. Kempf 2001-2002. All Rights Reserved.
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.
