Since the original author William E. Kempf no longer is available to maintain the Boost.Thread library, a new team has been formed in an attempt to continue the work on Boost.Thread. Fortunately William E. Kempf has given permission to use his work under the boost license.
The team currently consists of
Volunteers for other platforms are welcome!
As the Boost.Thread was kind of orphaned over the last release, this release attempts to fix the known bugs. Upcoming releases will bring in new things.
|It has been decided not to release the Read/Write Mutex, since the current implementation suffers from a serious bug. The documentation of the concepts has been included though, giving the interested reader an opportunity to study the original concepts. Please refer to the following links if you are interested which problems led to the decision to held back this mutex type.The issue has been discovered before 1.33 was released and the code has been omitted from that release. A reworked mutex is expected to appear in 1.35. Also see: read_write_mutex bug and read_write_mutex fundamentally broken in 1.33|
The documentation was converted to BoostBook format, and a number of errors and inconsistencies were fixed in the process. Since this was a fairly large task, there are likely to be more errors and inconsistencies remaining. If you find any, please report them!
The option to link Boost.Thread as a static
library has been added (with some limitations on Win32 platforms).
This feature was originally removed from an earlier version
of Boost because
required that Boost.Thread be dynamically linked in order
for its cleanup functionality to work on Win32 platforms.
Because this limitation never applied to non-Win32 platforms,
because significant progress has been made in removing
the limitation on Win32 platforms (many thanks to
Aaron LaFramboise and Roland Scwarz!), and because the lack
of static linking is one of the most common complaints of
Boost.Thread users, this decision was reversed.
On non-Win32 platforms: To choose the dynamically linked version of Boost.Thread using Boost's auto-linking feature, #define BOOST_THREAD_USE_DLL; to choose the statically linked version, #define BOOST_THREAD_USE_LIB. If neither symbols is #defined, the default will be chosen. Currently the default is the statically linked version.
On Win32 platforms using VC++: Use the same #defines as for non-Win32 platforms (BOOST_THREAD_USE_DLL and BOOST_THREAD_USE_LIB). If neither is #defined, the default will be chosen. Currently the default is the statically linked version if the VC++ run-time library is set to "Multi-threaded" or "Multi-threaded Debug", and the dynamically linked version if the VC++ run-time library is set to "Multi-threaded DLL" or "Multi-threaded Debug DLL".
On Win32 platforms using compilers other than VC++: Use the same #defines as for non-Win32 platforms (BOOST_THREAD_USE_DLL and BOOST_THREAD_USE_LIB). If neither is #defined, the default will be chosen. Currently the default is the dynamically linked version because it has not yet been possible to implement automatic tss cleanup in the statically linked version for compilers other than VC++, although it is hoped that this will be possible in a future version of Boost.Thread. Note for advanced users: Boost.Thread provides several "hook" functions to allow users to experiment with the statically linked version on Win32 with compilers other than VC++. These functions are on_process_enter(), on_process_exit(), on_thread_enter(), and on_thread_exit(), and are defined in tls_hooks.cpp. See the comments in that file for more information.
A new class,
boost::barrier, was added.
|Since the read/write mutex and related classes are new, both interface and implementation are liable to change in future releases of Boost.Thread. The lock concepts and lock promotion in particular are still under discussion and very likely to change.|
constructor now takes an optional pointer to a cleanup function that
is called to release the thread-specific data that is being pointed
Fixed: the number of available thread-specific storage "slots" is too small on some platforms.
doesn't check error returned by
tss::set() function now throws
if it fails instead of returning an error code).
causes double-delete: once when
is called and once when
boost::recursive_try_mutex now use a Win32 critical section
whenever possible; otherwise they use a Win32 mutex. As before,
boost::recursive_timed_mutex use a Win32 mutex.
Last revised: November 03, 2006 at 04:05:55 GMT
|Copyright © 2001-2003 William E. Kempf|