Fix compile errors: some compilers don't like an enum and the namespace it is in to have the same name; missing typename; _sntprintf not in namespace std for cw. Fix warnings on some compilers. Clean up scheduling algorithms to pass unit tests and hopefully eliminate reported deadlocks. Still needs work, but should be better than before.

[SVN r23859]

build/.cvsignore

@@ -0,0 +1,3 @@
+bin*
+*.pdb
+bjam.log

build/Jamfile

@@ -1,49 +1,132 @@
-#  (C) Copyright William E. Kempf 2001. Permission to copy, use, modify, sell and
-#  distribute this software is granted provided this copyright notice appears
-#  in all copies. This software is provided "as is" without express or implied
-#  warranty, and with no claim as to its suitability for any purpose.
+# Copyright (C) 2001-2003
+# William E. Kempf
 #
-# Boost.Threads build and test Jamfile
+# 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.
 #
-# Declares the following targets:
-#   1. libboost_thread, a static link library.
-#       1a. On Win32, a dynamic link library libboost_threadmon,
-#           which must be used in conjunction with libboost_thread.
+# Boost.Threads build Jamfile
+#
+# Additional configuration variables used:
+#   1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32
+#      library should be used instead of "native" threads. This feature is
+#      mostly used for testing and it's generally recommended you use the
+#      native threading libraries instead. PTW32 should be set to be a list
+#      of two strings, the first specifying the installation path of the
+#      pthreads-win32 library and the second specifying which library
+#      variant to link against (see the pthreads-win32 documentation).
+#      Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib"
 
-# declare the location of this subproject relative to the root
+# Declare the location of this subproject relative to the root.
 subproject libs/thread/build ;
 
-#######################
+# Include threads.jam for Boost.Threads global build information.
+# This greatly simplifies the Jam code needed to configure the build
+# for the various Win32 build types.
+import ./threads ;
 
-#
-# Declare the Boost.Threads static link library.
-#
-
-# For Win32 we need to build a special DLL, libboost_threadmon, to handle
-# TSS destruction.
-if $(NT)
 {
-    if $(PTW32)
+    CPP_SOURCES = 
+        barrier 
+        condition 
+        exceptions 
+        mutex 
+        named
+        once
+        recursive_mutex 
+        read_write_mutex
+        shared_memory 
+        thread 
+        threadmon 
+        thread_pool 
+        tss 
+        xtime 
+        ;
+
+    template boost_thread_lib_base
+        : ## sources ##
+          <template>thread_base
+          ../src/$(CPP_SOURCES).cpp
+        : ## requirements ##
+          <define>BOOST_THREAD_BUILD_LIB=1
+          <runtime-link>static
+          # the common names rule ensures that the library will
+          # be named according to the rules used by the install
+          # and auto-link features:
+          common-variant-tag 
+        : ## default build ##
+    ;
+
+    template thread_dll_base
+        : ## sources ##
+          <template>thread_base 
+          ../src/$(CPP_SOURCES).cpp
+        : ## requirements ##
+          <define>BOOST_THREAD_BUILD_DLL=1
+          <runtime-link>dynamic
+          # the common names rule ensures that the library will
+          # be named according to the rules used by the install
+          # and auto-link features:
+          common-variant-tag 
+        : ## default build ##
+    ;
+
+    lib $(boost_thread_lib_name)
+        : ## sources ##
+          <template>boost_thread_lib_base
+        : ## requirements ##
+          <define>BOOST_THREAD_LIB_NAME=$(boost_thread_lib_name)
+        : ## default build ##
+    ;
+
+    dll $(boost_thread_lib_name)
+        : ## sources ##
+          <template>thread_dll_base 
+        : ## requirements ##
+          <define>BOOST_THREAD_LIB_NAME=$(boost_thread_lib_name)
+        : ## default build ##
+    ;
+
+    stage bin-stage
+        : <dll>$(boost_thread_lib_name)
+          <lib>$(boost_thread_lib_name)
+    ;
+
+    install thread lib
+        : <dll>$(boost_thread_lib_name)
+          <lib>$(boost_thread_lib_name)
+    ;
+
+    if $(boost_thread_lib_settings_ptw32)
     {
-        PTW32_REQUIREMENTS = <define>BOOST_HAS_PTHREADS <define>PtW32NoCatchWarn ;
-    }
-    else
-    {
-        dll libboost_threadmon : ../src/threadmon.cpp
-            # requirements
-            : <include>$(BOOST_ROOT)
-            <threading>multi
-            : debug release ;
+        lib $(boost_thread_lib_name_ptw32)
+            : ## sources ##
+              <template>boost_thread_lib_base
+            : ## requirements ##
+              <define>BOOST_THREAD_LIB_NAME=$(boost_thread_lib_name_ptw32)
+              $(pthreads-win32)
+        ;
+
+        dll $(boost_thread_lib_name_ptw32)
+            : ## sources ##
+              <template>thread_dll_base
+            : ## requirements ##
+              <define>BOOST_THREAD_LIB_NAME=$(boost_thread_lib_name_ptw32)
+              $(pthreads-win32)
+        ;
+
+        stage bin-stage
+            : <dll>$(boost_thread_lib_name_ptw32)
+              <lib>$(boost_thread_lib_name_ptw32)
+        ;
+
+        install thread lib
+            : <dll>$(boost_thread_lib_name_ptw32)
+              <lib>$(boost_thread_lib_name_ptw32)
+        ;
     }
 }
-
-# Base names of the source files for libboost_thread
-CPP_SOURCES =
-    condition mutex recursive_mutex thread tss xtime once exceptions ;
-
-lib libboost_thread : ../src/$(CPP_SOURCES).cpp
-    # requirements
-    : <include>$(BOOST_ROOT)
-    $(PTW32_REQUIREMENTS)
-    <threading>multi
-    : debug release ;

build/Jamfile.v2

@@ -0,0 +1,12 @@
+
+# Declare the uses system library
+lib pthread : : <name>pthread ;
+
+project boost/thread
+    : source-location ../src 
+    : usage-requirements <library>pthread
+    ;
+
+CPP_SOURCES = condition mutex recursive_mutex thread tss xtime once exceptions ;
+
+lib boost_thread : $(CPP_SOURCES).cpp ;

build/threads.jam

@@ -0,0 +1,45 @@
+# Copyright (C) 2001-2003
+# William E. Kempf
+#
+# 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.
+
+# Do some OS-specific setup
+{
+    #thread library name
+    boost_thread_lib_name = boost_thread ; 
+    
+    #thread library name with "pthreads-win32" library
+    boost_thread_lib_name_ptw32 = boost_thread_ptw32 ;
+    
+    if $(NT)
+    {
+        if $(PTW32_DIR)
+        {
+            if $(PTW32_LIB)
+            {
+                boost_thread_lib_settings_ptw32 =
+                    <define>BOOST_HAS_PTHREADS
+                    <define>PtW32NoCatchWarn
+                    <include>$(PTW32_DIR)/pre-built/include
+                    <library-file>$(PTW32_DIR)/pre-built/lib/$(PTW32_LIB)
+                ;
+            }
+        }
+    }
+
+    template thread_base
+        : ## sources ##
+        : ## requirements ##
+          <sysinclude>$(BOOST_ROOT)
+          <threading>multi
+          <borland><*><cxxflags>-w-8004
+          <borland><*><cxxflags>-w-8057
+        : ## default build ##
+    ;
+}

doc/.cvsignore

@@ -0,0 +1,3 @@
+bin
+html
+catalog.xml

doc/Jamfile.v2

@@ -0,0 +1,5 @@
+project boost/doc ;
+import boostbook : boostbook ;
+
+boostbook doc : thread.xml ;
+

doc/acknowledgements.html

@@ -1,80 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=windows-1252">
-        <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-        <meta name="ProgId" content="FrontPage.Editor.Document">
-
-        <title>Boost.Threads Acknowledgements</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" text="#000000">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Acknowledgements</h2>
-                </td>
-            </tr>
-        </table>
-
-        <h2>Acknowledgments</h2>
-
-        <p><a href="../../../people/william_kempf.htm">William E. Kempf</a> was
-        the architect, designer, and implementor of <b>Boost.Threads</b>.</p>
-
-		<p>Mac OS Carbon implementation written by
-		<a href="../../../people/mac_murrett.htm">Mac Murrett</a>.</p>
-
-        <p>Important contributions were also made by Jeremy Siek (lots of input
-        on the design and on the implementation), Alexander Terekhov (lots of
-        input on the Win32 implementation, especially in regards to
-        boost::condition, as well as a lot of explanation of POSIX behavior),
-        Greg Colvin (lots of input on the design), and Paul Mclachlan, Thomas
-        Matelich and Iain Hanson (for help in trying to get the build to work
-        on other platforms).</p>
-
-        <p>The documentation was written by William E. Kempf. Beman Dawes
-        provided additional documentation material and editing.</p>
-
-        <p>Discussions on the boost.org mailing list were essential in the
-        development of <b>Boost.Threads</b>. As of August 1, 2001, participants
-        included Alan Griffiths, Albrecht Fritzsche, Aleksey Gurtovoy,
-        Alexander Terekhov, Andrew Green, Andy Sawyer, Asger Alstrup Nielsen,
-        Beman Dawes, Bill Klein, Bill Rutiser, Bill Wade, Branko &Egrave;ibej,
-        Brent Verner, Craig Henderson, Csaba Szepesvari, Dale Peakall, Damian
-        Dixon, Dan Nuffer, Darryl Green, Daryle Walker, David Abrahams, David
-        Allan Finch, Dejan Jelovic, Dietmar Kuehl, Doug Gregor, Douglas Gregor,
-        Duncan Harris, Ed Brey, Eric Swanson, Eugene Karpachov, Fabrice
-        Truillot, Frank Gerlach, Gary Powell, Gernot Neppert, Geurt Vos, Ghazi
-        Ramadan, Greg Colvin, Gregory Seidman, HYS, Iain Hanson, Ian Bruntlett,
-        J Panzer, Jeff Garland, Jeff Paquette, Jens Maurer, Jeremy Siek, Jesse
-        Jones, Joe Gottman, John (EBo) David, John Bandela, John Maddock, John
-        Max Skaller, John Panzer, Jon Jagger , Karl Nelson, Kevlin Henney, KG
-        Chandrasekhar, Levente Farkas, Lie-Quan Lee, Lois Goldthwaite, Luis
-        Pedro Coelho, Marc Girod, Mark A. Borgerding, Mark Rodgers, Marshall
-        Clow, Matthew Austern, Matthew Hurd, Michael D. Crawford, Michael H.
-        Cox , Mike Haller, Miki Jovanovic, Nathan Myers, Paul Moore, Pavel
-        Cisler, Peter Dimov, Petr Kocmid, Philip Nash, Rainer Deyke, Reid
-        Sweatman, Ross Smith, Scott McCaskill, Shalom Reich , Steve Cleary,
-        Steven Kirk, Thomas Holenstein, Thomas Matelich, Trevor Perrin,
-        Valentin Bonnard, Vesa Karvonen, Wayne Miller, and William Kempf.</p>
-
-        <p>Apologies for anyone inadvertently missed.</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>&copy; <i>Copyright <a href="mailto:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001</i></p>
-    </body>
-</html>
-

doc/acknowledgements.xml

@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="thread.acknowledgements"
+last-revision="$Date$">
+  <title>Acknowledgements</title>
+  <para>William E. Kempf was the architect, designer, and implementor of 
+  &Boost.Threads;.</para>
+  <para>Mac OS Carbon implementation written by Mac Murrett.</para>
+  <para>Dave Moore provided initial submissions and further comments on the 
+  <code>barrier</code>
+  , 
+  <code>thread_pool</code>
+  , 
+  <code>read_write_mutex</code>
+  , 
+  <code>read_write_try_mutex</code>
+  and 
+  <code>read_write_timed_mutex</code>
+  classes.</para>
+  <para>Important contributions were also made by Jeremy Siek (lots of input
+  on the design and on the implementation), Alexander Terekhov (lots of input
+  on the Win32 implementation, especially in regards to boost::condition, as
+  well as a lot of explanation of POSIX behavior), Greg Colvin (lots of input
+  on the design), Paul Mclachlan, Thomas Matelich and Iain Hanson (for help
+  in trying to get the build to work on other platforms), and Kevin S. Van
+  Horn (for several updates/corrections to the documentation).</para>
+  <para>Mike Glassford finished changes to &Boost.Threads; that were begun
+  by William Kempf and moved them into the main CVS branch.
+  He also addressed a number of issues that were brought up on the Boost
+  developer's mailing list and provided some additions and changes to the 
+  read_write_mutex and related classes.</para>
+  <para>The documentation was written by William E. Kempf. Beman Dawes
+  provided additional documentation material and editing.
+  Mike Glassford finished William Kempf's conversion of the documentation to 
+  BoostBook format and added a number of new sections.</para>
+  <para>Discussions on the boost.org mailing list were essential in the
+  development of &Boost.Threads;
+  . As of August 1, 2001, participants included Alan Griffiths, Albrecht
+  Fritzsche, Aleksey Gurtovoy, Alexander Terekhov, Andrew Green, Andy Sawyer,
+  Asger Alstrup Nielsen, Beman Dawes, Bill Klein, Bill Rutiser, Bill Wade,
+  Branko &egrave;ibej, Brent Verner, Craig Henderson, Csaba Szepesvari,
+  Dale Peakall, Damian Dixon, Dan Nuffer, Darryl Green, Daryle Walker, David
+  Abrahams, David Allan Finch, Dejan Jelovic, Dietmar Kuehl, Douglas Gregor,
+  Duncan Harris, Ed Brey, Eric Swanson, Eugene Karpachov, Fabrice Truillot,
+  Frank Gerlach, Gary Powell, Gernot Neppert, Geurt Vos, Ghazi Ramadan, Greg
+  Colvin, Gregory Seidman, HYS, Iain Hanson, Ian Bruntlett, J Panzer, Jeff
+  Garland, Jeff Paquette, Jens Maurer, Jeremy Siek, Jesse Jones, Joe Gottman,
+  John (EBo) David, John Bandela, John Maddock, John Max Skaller, John
+  Panzer, Jon Jagger , Karl Nelson, Kevlin Henney, KG Chandrasekhar, Levente
+  Farkas, Lie-Quan Lee, Lois Goldthwaite, Luis Pedro Coelho, Marc Girod, Mark
+  A. Borgerding, Mark Rodgers, Marshall Clow, Matthew Austern, Matthew Hurd,
+  Michael D. Crawford, Michael H. Cox , Mike Haller, Miki Jovanovic, Nathan
+  Myers, Paul Moore, Pavel Cisler, Peter Dimov, Petr Kocmid, Philip Nash,
+  Rainer Deyke, Reid Sweatman, Ross Smith, Scott McCaskill, Shalom Reich,
+  Steve Cleary, Steven Kirk, Thomas Holenstein, Thomas Matelich, Trevor
+  Perrin, Valentin Bonnard, Vesa Karvonen, Wayne Miller, and William
+  Kempf.</para>
+  <para>Apologies for anyone inadvertently missed.</para>
+</section>
+

doc/barrier-ref.xml

@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/barrier.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="barrier">
+      <inherit access="private">
+        <type><classname>boost::noncopyable</classname></type>
+        <purpose>Exposition only</purpose>
+      </inherit>
+
+      <purpose>
+        <para>An object of class <classname>barrier</classname> is a synchronization 
+        primitive used  to cause a set of threads to wait until they each perform a 
+        certain function or each reach a particular point in their execution.</para>
+      </purpose>
+
+      <description>
+		<para>When a barrier is created, it is initialized with a thread count N.
+		The first N-1 calls to <code>wait()</code> will all cause their threads to be blocked. 
+		The Nth call to <code>wait()</code> will allow all  of the waiting threads, including 
+		the Nth thread, to be placed in a ready state.  The Nth call will also "reset"
+		the barrier such that, if an additional N+1th call is made to <code>wait()</code>, 
+		it will be as though this were the first call to <code>wait()</code>; in other
+		words, the N+1th to 2N-1th calls to <code>wait()</code> will cause their
+		threads to be blocked, and the 2Nth call to <code>wait()</code> will allow all of 
+		the waiting threads, including the 2Nth thread, to be placed in a ready state
+		and reset the barrier. This functionality allows the same set of N threads to re-use 
+		a barrier object to  synchronize their execution at multiple points during their 
+		execution.</para>
+		<para>See <xref linkend="threads.glossary"/> for definitions of thread 
+		states <link linkend="threads.glossary.thread-state">blocked</link>
+		and <link linkend="threads.glossary.thread-state">ready</link>.
+		Note that "waiting" is a synonym for blocked.</para>
+      </description>
+      
+      <constructor>
+        <parameter name="count">
+	        <paramtype>size_t</paramtype>
+        </parameter>
+
+        <effects><simpara>Constructs a <classname>barrier</classname> object that 
+        will cause <code>count</code> threads to block on a call to <code>wait()</code>.
+        </simpara></effects>
+      </constructor>
+
+      <destructor>
+        <effects><simpara>Destroys <code>*this</code>. If threads are still executing 
+		their <code>wait()</code> operations, the behavior for these threads is undefined.
+		</simpara></effects>
+      </destructor>
+
+      <method-group name="waiting">
+        <method name="wait">
+          <type>bool</type>
+
+          <effects><simpara>Wait until N threads call <code>wait()</code>, where
+          N equals the <code>count</code> provided to the constructor for the 
+          barrier object.</simpara>
+          <simpara><emphasis role="bold">Note</emphasis> that if the barrier is 
+          destroyed before <code>wait()</code> can return, the behavior is 
+          undefined.</simpara></effects>
+          
+          <returns>Exactly one of the N threads will receive a return value
+		  of <code>true</code>, the others will receive a value of <code>false</code>. 
+		  Precisely which thread receives the return value of <code>true</code> will 
+		  be implementation-defined. Applications can use this value to designate one 
+		  thread as a leader that will take a certain action, and the other threads 
+		  emerging from the barrier can wait for that action to take place.</returns>
+        </method>		
+      </method-group>
+	</class>
+  </namespace>
+</header>

doc/bibliography.html

@@ -1,222 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=windows-1252">
-        <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-        <meta name="ProgId" content="FrontPage.Editor.Document">
-
-        <title>Boost.Threads Bibliography</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" text="#000000">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Bibliography</h2>
-                </td>
-            </tr>
-        </table>
-
-        <h2>Bibliography</h2>
-
-        <table summary="Bibliography" border="0" cellpadding="5" width="777">
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Andrews-83">Andrews 83</a>]</b></td>
-
-                <td width="645">
-                    Gregory R. Andrews, Fred B. Schneider, <cite>Concepts and
-                    Notations for Concurrent Programming</cite>, ACM Computing
-                    Surveys, Vol. 15, No. 1, March, 1983. <a href=
-                    "http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/">
-                    http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/</a>
-                    
-
-                    <p>Good general background reading. Includes descriptions
-                    of Path Expressions, Message Passing, and Remote Procedure
-                    Call in addition to the basics.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Boost">Boost</a>]</b></td>
-
-                <td width="645">
-                    The <cite>Boost</cite> world-wide web site. <a href=
-                    "http://www.boost.org">http://www.boost.org</a> 
-
-                    <p>Boost.Threads is one of many Boost libraries. The Boost
-                    web site includes a great deal of documentation and general
-                    information which applies to all Boost libraries. Current
-                    copies of the libraries including documentation and test
-                    programs may be downloaded from the web site.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Brinch-Hansen-73">Brinch Hansen 73</a>]</b></td>
-
-                <td width="645">
-                    Per Brinch Hansen, <cite>Concurrent Programming
-                    Concepts</cite>, ACM Computing Surveys, Vol. 5, No. 4,
-                    December, 1973. <a href=
-                    "http://www.acm.org/pubs/articles/journals/surveys/1973-5-4/p223-hansen/p223-hansen.pdf">
-                    http://www.acm.org/pubs/articles/journals/surveys/1973-5-4/p223-hansen/</a>
-                    
-
-                    <p>&quot;This paper describes the evolution of language
-                    features for multiprogramming from event queues and
-                    semaphores to critical regions and monitors.&quot; Includes
-                    analysis of why <i>events</i> are considered error-prone.
-                    Also noteworthy because of an introductory quotation from
-                    Christopher Alexander; Brinch Hansen was years ahead of
-                    others in recognizing pattern concepts applied to software
-                    too.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>]<a name=
-                "Butenhof-97">Butenhof 97</a>]</b></td>
-
-                <td width="645">
-                    <p>David R. Butenhof, <cite>Programming with POSIX
-                    Threads</cite>, Addison-Wesley 1997, ISBN 0-201-63392-2 <a
-                    href="http://cseng.aw.com/book/0,3828,0201633922,00.html">
-                    http://cseng.aw.com/book/0,3828,0201633922,00.html</a></p>
-
-                    <p>This is a very readable explanation of threads and how
-                    to use them. Many of the insights given apply to all
-                    multi-threaded programming, not just POSIX Threads.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Hoare-74">Hoare 74</a>]</b></td>
-
-                <td width="645">
-                    <p>C.A.R Hoare, <cite>Monitors: An Operating System
-                    Structuring Concept</cite>, Communications of the ACM, Vol.
-                    17, No. 10. October 1974, pp. 549-557 <a href=
-                    "http://www.acm.org/classics/feb96/">
-                    http://www.acm.org/classics/feb96/</a></p>
-
-                    <p>Hoare and Brinch Hansen&#39;s work on Monitors is the
-                    basis for reliable multi-threading patterns. This is one of
-                    the most often referenced papers in all of computer
-                    science, and with good reason.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "ISO-98">ISO 98</a>]</b></td>
-
-                <td width="645">
-                    <p>ISO/IEC 14882:1998(E) <cite>Programming Language
-                    C++</cite> <a href="http://www.ansi.org">
-                    http://www.ansi.org</a></p>
-
-                    <p>This is the official C++ Standards document. Available
-                    from the ANSI (American National Standards Institute)
-                    Electronic Standards Store.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "McDowell-89">McDowell 89</a>]</b></td>
-
-                <td width="645">
-                    Charles E McDowell, David P. Helmbold, <cite>Debugging
-                    Concurrent Programs</cite>, ACM Computing Surveys, Vol. 21,
-                    No. 2, December, 1989. <a href=
-                    "http://www.acm.org/pubs/citations/journals/surveys/1989-21-4/p593-mcdowell/">
-                    http://www.acm.org/pubs/citations/journals/surveys/1989-21-4/p593-mcdowell/</a>
-                    
-
-                    <p>Identifies many of the unique failure modes and
-                    debugging difficulties associated with concurrent
-                    programs.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Schmidt">Schmidt</a>]</b> </td>
-
-                <td width="645">
-                    <p>Douglas C. Schmidt and Irfan Pyarali, <cite>Strategies
-                    for Implementing POSIX Condition Variables on Win32</cite>,
-                    Department of Computer Science, Washington University, St.
-                    Louis, Missouri. <a href=
-                    "http://www.cs.wustl.edu/~schmidt/win32-cv-1.html">
-                    http://www.cs.wustl.edu/~schmidt/win32-cv-1.html</a></p>
-
-                    <p>Rationale for understanding Boost.Threads condition
-                    variables. Note that Alexander Terekhov found some bugs in
-                    the implementation given in this article, so pthreads-win32
-                    and Boost.Threads are even more complicated yet.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Schmidt-00">Schmidt 00</a>]</b> </td>
-
-                <td width="645">
-                    <p>Douglas C. Schmidt, Michael Stal, Hans Rohnert and Frank
-                    Buschmann, <cite>Pattern-Oriented Software Architecture
-                    Volume 2 - Patterns for Concurrent and Networked
-                    Objects</cite>, Wiley 2000, ISBN 0-471-60695-2 <a href=
-                    "http://www.wiley.com/Corporate/Website/Objects/Products/0,9049,104671,00.html">
-                    http://www.wiley.com/Corporate/Website/Objects/Products/0,9049,104671,00.html</a></p>
-
-                    <p>This is a very good explanation of how to apply several
-                    patterns useful for concurrent programming. Among the
-                    patterns documented is the Monitor Pattern mentioned
-                    frequently in the <b>Boost.Threads</b> documentation.</p>
-                </td>
-            </tr>
-
-            <tr>
-                <td width="102" valign="top" align="left"><b>[<a name=
-                "Stroustrup-00">Stroustrup 00</a>]</b></td>
-
-                <td width="645">
-                    Bjarne Stroustrup, <cite>The C++ Programming
-                    Language</cite>, Special Edition, Addison-Wesley 2000, ISBN
-                    0-201-70073-5 <a href=
-                    "http://cseng.aw.com/book/0,3828,0201700735,00.html">
-                    http://cseng.aw.com/book/0,3828,0201700735,00.html</a> 
-
-                    <p>The first book a C++ programmer should own. Note that
-                    the 3rd edition (and subsequent editions like the Special
-                    Edition) has been rewritten to cover the ISO standard
-                    language and library.</p>
-                </td>
-            </tr>
-        </table>
-
-        <p>Note: The URL&#39;s above are provided in plain text form so that
-        they will be visible on printed copies of this document.</p>
-        <hr>
-
-        <p>Revised 
-        <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %b %Y" startspan -->05 Nov 2001<!--webbot bot="Timestamp" endspan i-checksum="15246" --></p>
-
-        <p>&copy; Copyright Beman Dawes, 2001</p>
-    </body>
-</html>
-

doc/bibliography.xml

@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<bibliography id="threads.bibliography"
+last-revision="$Date$">
+  <title>Bibliography</title>
+  <biblioentry id="threads.bib.AndrewsSchneider83">
+    <abbrev id="threads.bib.AndrewsSchneider83.abbrev">AndrewsSchnieder83</abbrev>
+    <biblioset relation="journal">
+      <title>ACM Computing Surveys</title>
+      <volumenum>Vol. 15</volumenum>
+      <issuenum>No. 1</issuenum>
+      <date>March, 1983</date>
+    </biblioset>
+    <biblioset relation="article">
+      <authorgroup>
+        <author>
+          <firstname>Gregory</firstname>
+          <othername>R.</othername>
+          <surname>Andrews</surname>
+        </author>
+        <author>
+          <firstname>Fred</firstname>
+          <othername>B.</othername>
+          <surname>Schneider</surname>
+        </author>
+      </authorgroup>
+      <title>
+        <ulink
+        url="http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/"
+        >Concepts and Notations for Concurrent Programming</ulink>
+      </title>
+    </biblioset>
+    <para>Good general background reading. Includes descriptions of Path
+    Expressions, Message Passing, and Remote Procedure Call in addition to the
+    basics</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.Boost">
+    <abbrev id="threads.bib.Boost.abbrev">Boost</abbrev>
+    <bibliomisc>The <emphasis>Boost</emphasis> world wide web site.
+	<ulink url="http:/www.boost.org">http://www.boost.org</ulink></bibliomisc>
+	<para>&Boost.Threads; is one of many Boost libraries. The Boost web
+    site includes a great deal of documentation and general information which
+    applies to all Boost libraries. Current copies of the libraries including
+    documentation and test programs may be downloaded from the web
+    site.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.Hansen73">
+    <abbrev id="threads.bib.Hansen73.abbrev">Hansen73</abbrev>
+    <biblioset relation="journal">
+      <title>ACM Computing Surveys</title>
+      <volumenum>Vol. 5</volumenum>
+      <issuenum>No. 4</issuenum>
+      <date>December, 1983</date>
+    </biblioset>
+    <biblioset relation="article">
+      <author>0-201-63392-2 
+        <firstname>Per Brinch</firstname>
+        <lastname>Hansen</lastname>
+      </author>
+      <title>
+        <ulink
+        url="http://www.acm.org/pubs/articles/journals/surveys/1973-5-4/p223-hansen/"
+        >Concurrent Programming Concepts</ulink>
+      </title>
+    </biblioset>
+    <para>"This paper describes the evolution of language features for
+    multiprogramming from event queues and semaphores to critical regions and
+    monitors." Includes analysis of why events are considered error-prone. Also
+    noteworthy because of an introductory quotation from Christopher Alexander;
+    Brinch Hansen was years ahead of others in recognizing pattern concepts
+    applied to software, too.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.Butenhof97">
+    <abbrev id="threads.bib.Butenhof97.abbrev">Butenhof97</abbrev>
+	<title>
+	  <ulink url="http://cseng.aw.com/book/0,3828,0201633922,00.html"
+	  >Programming with POSIX Threads </ulink>
+	</title>
+	<author>
+	  <firstname>David</firstname>
+	  <othername>R.</othername>
+	  <surname>Butenhof</surname>
+	</author>
+	<publisher>Addison-Wesley</publisher>
+	<copyright><year>1997</year></copyright>
+	<isbn>ISNB: 0-201-63392-2</isbn>
+	<para>This is a very readable explanation of threads and how to use
+	them. Many of the insights given apply to all multithreaded programming, not
+	just POSIX Threads</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.Hoare74">
+    <abbrev id="threads.bib.Hoare74.abbrev">Hoare74</abbrev>
+	<biblioset relation="journal">
+	  <title>Communications of the ACM</title>
+	  <volumenum>Vol. 17</volumenum>
+	  <issuenum>No. 10</issuenum>
+	  <date>October, 1974</date>
+	</biblioset>
+	<biblioset relation="article">
+      <title>
+	    <ulink url=" http://www.acm.org/classics/feb96/"
+	    >Monitors: An Operating System Structuring Concept</ulink>
+      </title>
+      <author>
+        <firstname>C.A.R.</firstname>
+        <surname>Hoare</surname>
+      </author>
+	  <pagenums>549-557</pagenums>
+	</biblioset>
+	<para>Hoare and Brinch Hansen's work on Monitors is the basis for reliable
+	multithreading patterns. This is one of the most often referenced papers in
+	all of computer science, and with good reason.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.ISO98">
+    <abbrev id="threads.bib.ISO98.abbrev">ISO98</abbrev>
+	<title>
+	  <ulink url="http://www.ansi.org">Programming Language C++</ulink>
+	</title>
+	<orgname>ISO/IEC</orgname>
+    <releaseinfo>14882:1998(E)</releaseinfo>
+	<para>This is the official C++ Standards document. Available from the ANSI
+	(American National Standards Institute) Electronic Standards Store.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.McDowellHelmbold89">
+    <abbrev id="threads.bib.McDowellHelmbold89.abbrev">McDowellHelmbold89</abbrev>
+	<biblioset relation="journal">
+	  <title>Communications of the ACM</title>
+	  <volumenum>Vol. 21</volumenum>
+	  <issuenum>No. 2</issuenum>
+	  <date>December, 1989</date>
+	</biblioset>
+	<biblioset>
+	  <author>
+	    <firstname>Charles</firstname>
+		<othername>E.</othername>
+		<surname>McDowell</surname>
+	  </author>
+	  <author>
+	    <firstname>David</firstname>
+		<othername>P.</othername>
+		<surname>Helmbold</surname>
+	  </author>
+	  <title>
+	    <ulink
+		url="http://www.acm.org/pubs/citations/journals/surveys/1989-21-4/p593-mcdowell/"
+		>Debugging Concurrent Programs</ulink>
+	  </title>
+	</biblioset>
+	<para>Identifies many of the unique failure modes and debugging difficulties
+	associated with concurrent programs.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.SchmidtPyarali">
+    <abbrev id="threads.bib.SchmidtPyarali.abbrev">SchmidtPyarali</abbrev>
+	<title>
+	  <ulink url="http://www.cs.wustl.edu/~schmidt/win32-cv-1.html8"
+	  >Strategies for Implementing POSIX Condition Variables on Win32</ulink>
+	</title> 
+	<authorgroup>
+	  <author>
+	    <firstname>Douglas</firstname>
+		<othername>C.</othername>
+		<surname>Schmidt</surname>
+	  </author>
+	  <author>
+	    <firstname>Irfan</firstname>
+		<surname>Pyarali</surname>
+	  </author>
+	</authorgroup>
+	<orgname>Department of Computer Science, Washington University, St. Louis,
+	Missouri</orgname>
+	<para>Rationale for understanding &Boost.Threads; condition
+	variables. Note that Alexander Terekhov found some bugs in the
+	implementation given in this article, so pthreads-win32 and &Boost.Threads;
+	are even more complicated yet.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.SchmidtStalRohnertBuschmann">
+    <abbrev
+	id="threads.bib.SchmidtStalRohnertBuschmann.abbrev">SchmidtStalRohnertBuschmann</abbrev>
+	<title>
+	  <ulink
+	  url="http://www.wiley.com/Corporate/Website/Objects/Products/0,9049,104671,00.html"
+	  >Pattern-Oriented Architecture Volume 2</ulink>
+	</title>
+	<subtitle>Patterns for Concurrent and Networked Objects</subtitle>
+	<titleabbrev>POSA2</titleabbrev>
+	<authorgroup>
+	  <author>
+	    <firstname>Douglas</firstname>
+		<othername>C.</othername>
+		<surname>Schmidt</surname>
+	  </author>
+	  <author>
+	    <firstname>Michael</firstname>
+		<lastname>Stal</lastname>
+	  </author>
+	  <author>
+	    <firstname>Hans</firstname>
+		<surname>Rohnert</surname>
+	  </author>
+	  <author>
+	    <firstname>Frank</firstname>
+		<surname>Buschmann</surname>
+	  </author>
+	</authorgroup>
+	<publisher>Wiley</publisher>
+	<copyright><year>2000</year></copyright>
+	<para>This is a very good explanation of how to apply several patterns
+	useful for concurrent programming. Among the patterns documented is the
+	Monitor Pattern mentioned frequently in the &Boost.Threads;
+	documentation.</para>
+  </biblioentry>
+  <biblioentry id="threads.bib.Stroustrup">
+    <abbrev id="threads.bib.Stroustrup.abbrev">Stroustrup</abbrev>
+	<title>
+	  <ulink url="http://cseng.aw.com/book/0,3828,0201700735,00.html"
+	  >The C++ Programming Language</ulink>
+	</title>
+	<edition>Special Edition</edition>
+	<publisher>Addison-Wesley</publisher>
+	<copyright><year>2000</year></copyright>
+	<isbn>ISBN: 0-201-70073-5</isbn>
+	<para>The first book a C++ programmer should own. Note that the 3rd edition
+	(and subsequent editions like the Special Edition) has been rewritten to
+	cover the ISO standard language and library.</para>
+  </biblioentry>
+</bibliography>

doc/build.xml

@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="thread.build" last-revision="$Date$">
+	<title>Build</title>
+	<para>
+	How you build the &Boost.Threads; libraries, and how you build your own applications
+	that use those libraries, are some of the most frequently asked questions. Build
+	processes are difficult to deal with in a portable manner. That's one reason
+	why &Boost.Threads; makes use of &Boost.Build;.
+	In general you should refer to the documentation for &Boost.Build;.
+	This document will only supply you with some simple usage examples for how to
+	use <emphasis>bjam</emphasis> to build and test &Boost.Threads;. In addition, this document
+	will try to explain the build requirements so that users may create their own
+	build processes (for instance, create an IDE specific project), both for building
+	and testing &Boost.Threads;, as well as for building their own projects using
+	&Boost.Threads;.
+	</para>
+	<section id="thread.build.building">
+		<title>Building the &Boost.Threads; Libraries</title>
+		<para>
+	To build the &Boost.Threads; libraries using &Boost.Build;, simply change to the
+	directory <emphasis>boost_root</emphasis>/libs/thread/build and execute the command:
+		<programlisting>bjam -sTOOLS=<emphasis>toolset</emphasis></programlisting>
+	This will create the debug and the release builds of the &Boost.Threads; library.
+	<note>Invoking the above command in <emphasis>boost_root</emphasis> will build all of 
+	the Boost distribution, including &Boost.Threads;.</note>
+		</para>
+		<para>
+	The Jamfile supplied with &Boost.Threads; produces a dynamic link library named
+	<emphasis>boost_thread{build-specific-tags}.{extension}</emphasis>, where the build-specific
+	tags indicate the toolset used to build the library, whether it's a debug or release
+	build, what version of Boost was used, etc.; and the extension is the appropriate extension
+	for a dynamic link library for the platform for which &Boost.Threads; is being built.
+	For instance, a debug library built for Win32 with VC++ 7.1 using Boost 1.31 would
+	be named <emphasis>boost_thread-vc71-mt-gd-1_31.dll</emphasis>.
+		</para>
+		<para>
+	The source files that are used to create the &Boost.Threads; library
+	are all of the *.cpp files found in <emphasis>boost_root</emphasis>/libs/thread/src.
+	These need to be built with the compiler's and linker's multi-threading support enabled.
+	If you want to create your own build solution you'll have to follow these same
+	guidelines. One of the most frequently reported problems when trying to do this
+	occurs from not enabling the compiler's and linker's support for multi-threading.
+		</para>
+	</section>
+	<section id="thread.build.testing">
+		<title>Testing the &Boost.Threads; Libraries</title>
+		<para>
+	To test the &Boost.Threads; libraries using &Boost.Build;, simply change to the
+	directory <emphasis>boost_root</emphasis>/libs/thread/test and execute the command:
+			<programlisting>bjam -sTOOLS=<emphasis>toolset</emphasis> test</programlisting>
+		</para>
+	</section>
+</section>

doc/call_once.html

@@ -1,132 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content=
-        "threads, Boost.Threads, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, call_once</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">call_once</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>call_once</code> routine and <code>once_flag</code> type
-        can be used to run a routine exactly once. This can be used to
-        initialize data in a <a href="definitions.html#Thread-safe">
-        thread-safe</a> manner.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/once.hpp">&lt;boost/thread/once.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost {
-
-typedef <i>[implementation defined]</i> once_flag;
-const once_flag once_init = <i>[implementation defined]</i>;
-void call_once(void (*func)(), once_flag&amp; flag);
-
-} // namespace boost
-</pre>
-
-        <h2><a name="Reference">Reference</a></h2>
-        <hr>
-
-        <h3>once_flag</h3>
-
-        <p>This implementation defined type is used as a flag to insure a
-        routine is called only once. Instances of this type should be
-        statically initialized to <code>once_init</code>.</p>
-        <hr>
-
-        <h3>once_init</h3>
-
-        <p>This is a constant value used to initialize <code>once_flag</code>
-        instances to indicate that the logically associated routine has not
-        been run yet.</p>
-        <hr>
-
-        <h3>call_once</h3>
-<pre>
-   void call_once(void (*func)(), once_flag&amp; flag);
-</pre>
-
-        <p><b>Requires:</b> The function <code>func</code> shall not throw
-        exceptions.</p>
-
-        <p><b>Effects:</b> As if (in an atomic fashion)</p>
-        <code>&nbsp;&nbsp;&nbsp;if (flag == once_init)<br>
-         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;func();</code> 
-
-        <p><b>Postcondition:</b> <code>flag</code> != <code>
-        once_init</code></p>
-        <hr>
-
-        <h2><a name="Example">Example Usage</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/tss.hpp">&lt;boost/thread/once.hpp&gt;</a>
-#include &lt;cassert&gt;
-
-int value=0;
-boost::once_flag once = boost::once_init;
-
-void init()
-{
-    ++value;
-}
-
-void thread_proc()
-{
-   boost::call_once(&amp;init, once);
-}
-
-int main(int argc, char* argv[])
-{
-   boost::thread_group threads;
-   for (int i=0; i&lt;5; ++i)
-      threads.create_thread(&amp;thread_proc);
-   threads.join_all();
-   assert(value == 1);
-}
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/condition-ref.xml

@@ -0,0 +1,188 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/condition.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="condition">
+      <inherit access="private">
+        <type><classname>boost::noncopyable</classname></type>
+        <purpose>Exposition only</purpose>
+      </inherit>
+
+      <purpose>
+        <para>An object of class <classname>condition</classname> is a
+          synchronization primitive used to cause a thread to wait until a
+          particular shared-data condition (or time) is met.</para>
+      </purpose>
+
+      <description>
+        <para>A <classname>condition</classname> object is always used in
+          conjunction with a <link linkend="threads.concepts.mutexes">mutex</link>
+          object (an object whose type is a model of a <link
+            linkend="threads.concepts.Mutex">Mutex</link> or one of its
+          refinements). The mutex object must be locked prior to waiting on the
+          condition, which is verified by passing a lock object (an object whose
+          type is a model of <link linkend="threads.concepts.Lock">Lock</link> or
+          one of its refinements) to the <classname>condition</classname> object's
+          wait functions. Upon blocking on the <classname>condition</classname>
+          object, the thread unlocks the mutex object. When the thread returns
+          from a call to one of the <classname>condition</classname> object's wait
+          functions the mutex object is again locked. The tricky unlock/lock
+          sequence is performed automatically by the
+          <classname>condition</classname> object's wait functions.</para>
+        <para>The <classname>condition</classname> type is often used to
+          implement the Monitor Object and other important patterns (see
+          &cite.SchmidtStalRohnertBuschmann; and &cite.Hoare74;). Monitors are one
+          of the most important patterns for creating reliable multithreaded
+          programs.</para>
+        <para>See <xref linkend="threads.glossary"/> for definitions of <link
+            linkend="threads.glossary.thread-state">thread states</link>
+          blocked and ready. Note that "waiting" is a synonym for blocked.</para>
+      </description>
+
+      <constructor>
+        <effects><simpara>Constructs a <classname>condition</classname>
+            object.</simpara></effects>
+      </constructor>
+
+      <destructor>
+        <effects><simpara>Destroys <code>*this</code>.</simpara></effects>
+      </destructor>
+
+      <method-group name="notification">
+        <method name="notify_one">
+          <type>void</type>
+          <effects><simpara>If there is a thread waiting on <code>*this</code>,
+              change that thread's state to ready. Otherwise there is no
+              effect.</simpara></effects>
+          <notes><simpara>If more than one thread is waiting on <code>*this</code>,
+              it is unspecified which is made ready. After returning to a ready
+              state the notified thread must still acquire the mutex again (which
+              occurs within the call to one of the <classname>condition</classname>
+              object's wait functions.)</simpara></notes>
+        </method>
+
+        <method name="notify_all">
+          <type>void</type>
+          <effects><simpara>Change the state of all threads waiting on
+              <code>*this</code> to ready. If there are no waiting threads,
+              <code>notify_all()</code> has no effect.</simpara></effects>
+        </method>
+      </method-group>
+
+      <method-group name="waiting">
+        <method name="wait">
+          <template>
+            <template-type-parameter name="ScopedLock"/>
+          </template>
+
+          <type>void</type>
+
+          <parameter name="lock">
+            <paramtype>ScopedLock&amp;</paramtype>
+          </parameter>
+
+          <requires><simpara><code>ScopedLock</code> meets the <link
+                linkend="threads.concepts.ScopedLock">ScopedLock</link>
+              requirements.</simpara></requires>
+          <effects><simpara>Releases the lock on the <link
+                linkend="threads.concepts.mutexes">mutex object</link>
+              associated with <code>lock</code>, blocks the current thread of execution
+              until readied by a call to <code>this->notify_one()</code>
+              or<code> this->notify_all()</code>, and then reacquires the
+              lock.</simpara></effects>
+          <throws><simpara><classname>lock_error</classname> if
+              <code>!lock.locked()</code></simpara></throws>
+        </method>
+
+        <method name="wait">
+          <template>
+            <template-type-parameter name="ScopedLock"/>
+            <template-type-parameter name="Pred"/>
+          </template>
+
+          <type>void</type>
+
+          <parameter name="lock">
+            <paramtype>ScopedLock&amp;</paramtype>
+          </parameter>
+
+          <parameter name="pred">
+            <paramtype>Pred</paramtype>
+          </parameter>
+
+          <requires><simpara><code>ScopedLock</code> meets the <link
+                linkend="threads.concepts.ScopedLock">ScopedLock</link>
+              requirements and the return from <code>pred()</code> is
+              convertible to <code>bool</code>.</simpara></requires>
+          <effects><simpara>As if: <code>while (!pred())
+                wait(lock)</code></simpara></effects>
+          <throws><simpara><classname>lock_error</classname> if
+              <code>!lock.locked()</code></simpara></throws>
+        </method>
+
+        <method name="timed_wait">
+          <template>
+            <template-type-parameter name="ScopedLock"/>
+          </template>
+
+          <type>bool</type>
+
+          <parameter name="lock">
+            <paramtype>ScopedLock&amp;</paramtype>
+          </parameter>
+
+          <parameter name="xt">
+            <paramtype>const <classname>boost::xtime</classname>&amp;</paramtype>
+          </parameter>
+
+          <requires><simpara><code>ScopedLock</code> meets the <link
+                linkend="threads.concepts.ScopedLock">ScopedLock</link>
+              requirements.</simpara></requires>
+          <effects><simpara>Releases the lock on the <link
+                linkend="threads.concepts.mutexes">mutex object</link>
+              associated with <code>lock</code>, blocks the current thread of execution
+              until readied by a call to <code>this->notify_one()</code>
+              or<code> this->notify_all()</code>, or until time <code>xt</code> 
+              is reached, and then reacquires the lock.</simpara></effects>
+          <returns><simpara><code>false</code> if time <code>xt</code> is reached,
+              otherwise <code>true</code>.</simpara></returns>
+          <throws><simpara><classname>lock_error</classname> if
+              <code>!lock.locked()</code></simpara></throws>
+        </method>
+
+        <method name="timed_wait">
+          <template>
+            <template-type-parameter name="ScopedLock"/>
+            <template-type-parameter name="Pred"/>
+          </template>
+
+          <type>bool</type>
+
+          <parameter name="lock">
+            <paramtype>ScopedLock&amp;</paramtype>
+          </parameter>
+
+          <parameter name="pred">
+            <paramtype>Pred</paramtype>
+          </parameter>
+
+          <requires><simpara><code>ScopedLock</code> meets the <link
+                linkend="threads.concepts.ScopedLock">ScopedLock</link>
+              requirements and the return from <code>pred()</code> is
+              convertible to <code>bool</code>.</simpara></requires>
+          <effects><simpara>As if: <code>while (!pred()) { if (!timed_wait(lock,
+                xt)) return false; } return true;</code></simpara></effects>
+          <returns><simpara><code>false</code> if <code>xt</code> is reached,
+              otherwise <code>true</code>.</simpara></returns>
+          <throws><simpara><classname>lock_error</classname> if
+              <code>!lock.locked()</code></simpara></throws>
+        </method>
+      </method-group>
+    </class>
+  </namespace>
+</header>

doc/condition.html

@@ -1,338 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, condition</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080" text="#000000">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">condition</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>An object of class <code>condition</code> is a synchronization
-        primitive used to cause a thread to wait until a particular shared-data
-        condition (or time) is met. A <code>condition</code> object is always
-        used in conjunction with a mutex object modeling a <a href=
-        "mutex_concept.html">Mutex Concept</a>. The mutex must be locked prior
-        to waiting on the <code>condition</code>, which is ensured by passing a
-        lock object modeling a <a href="lock_concept.html">Lock Concept</a> to
-        the <code>condition</code> object&#39;s <code>wait</code> functions.
-        While the thread is waiting on the <code>condition</code> object, the
-        mutex associated with the lock is unlocked. When the thread returns
-        from a call to one of the <code>condition</code> object&#39;s <code>
-        wait</code> functions, the mutex is again locked. The tricky
-        lock/unlock/lock sequence is performed automatically by the <code>
-        condition</code> object&#39;s <code>wait</code> functions.</p>
-
-        <p>The <code>condition</code> type is often used to implement the <i>
-        Monitor Object</i> and other important patterns. See <a href=
-        "bibliography.html#Schmidt-00">[Schmidt-00]</a> and <a href=
-        "bibliography.html#Hoare-74">[Hoare 74]</a>. Monitors are one of the
-        most important patterns for creating reliable multithreaded
-        programs.</p>
-
-        <p>See <a href="definitions.html">Formal Definitions</a> for
-        definitions of thread states <a href="definitions.html#state">
-        blocked</a> and <a href="definitions.html#state">ready</a>. Note that
-        &quot;waiting&quot; is a synonym for blocked.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/condition.hpp">&lt;boost/thread/condition.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost { 
-
-class condition : private <a href=
-"../../utility/utility.htm#Class noncopyable">boost::noncopyable</a> // Exposition only.
-   // Class condition meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-{
-public:
-   condition();
-   ~condition();
-
-   void notify_one();
-   void notify_all();
-   template &lt;typename <a href="scoped_lock.html">ScopedLock</a>&gt;
-      void wait(<a href="scoped_lock.html">ScopedLock</a>&amp; lock);
-   template &lt;typename <a href="scoped_lock.html">ScopedLock</a>, typename <a
-href="http://www.sgi.com/tech/stl/Predicate.html">Predicate</a>&gt;
-      void wait(<a href="scoped_lock.html">ScopedLock</a>&amp; lock, <a href=
-"http://www.sgi.com/tech/stl/Predicate.html">Predicate</a> pred);
-   template &lt;typename <a href="scoped_lock.html">ScopedLock</a>&gt;
-      bool timed_wait(<a href=
-"scoped_lock.html">ScopedLock</a>&amp; lock, const xtime&amp; xt);
-   template &lt;typename <a href="scoped_lock.html">ScopedLock</a>, typename <a
-href="http://www.sgi.com/tech/stl/Predicate.html">Predicate</a>&gt;
-      bool timed_wait(<a href=
-"scoped_lock.html">ScopedLock</a>&amp; lock, const xtime&amp; xt, <a href=
-"http://www.sgi.com/tech/stl/Predicate.html">Predicate</a> pred);
-};
-
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-condition();
-</pre>
-
-        <p><b>Effects:</b> Constructs a <code>condition</code>.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-~condition();
-</pre>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-        <hr>
-
-        <h3>notify_one</h3>
-<pre>
-void notify_one();
-</pre>
-
-        <p><b>Effects:</b> If there is a thread waiting on <code>*this</code>,
-        change that thread&#39;s state to ready. Otherwise there is no
-        effect.</p>
-
-        <p><b>Notes:</b> If more that one thread is waiting on the condition,
-        it is unspecified which is made ready.</p>
-        <hr>
-
-        <h3>notify_all</h3>
-<pre>
-void notify_all();
-</pre>
-
-        <p><b>Effects:</b> Change the state of all threads waiting on <code>
-        *this</code> to ready. If there are no waiting threads, <code>
-        notify_all()</code> has no effect.</p>
-        <hr>
-
-        <h3>wait</h3>
-<pre>
-template &lt;typename ScopedLock&gt;
-   void wait(ScopedLock&amp; lock);
-</pre>
-
-        <p><b>Requires:</b> ScopedLock meets the <a href=
-        "lock_concept.html#ScopedLock">ScopedLock</a> requirements.</p>
-
-        <p><b>Effects:</b> Releases the lock on the <a href=
-        "mutex_concept.html">mutex model</a> associated with <code>lock</code>,
-        blocks the current thread of execution until readied by a call to
-        <code>this-&gt;notify_one()</code> or <code>
-        this-&gt;notify_all()</code>, and then reacquires the lock. All effects
-        occur in an atomic fashion.</p>
-
-        <p><b>Throws:</b> <code><a href="lock_error.html">lock_error</a></code>
-        if <code>!lock.locked()</code></p>
-
-        <p><b>Danger:</b> This version should always be used within a loop
-        checking that the state logically associated with the <code>
-        condition</code> has become true. Without the loop, race conditions can
-        ensue due to possible &quot;spurious wake ups&quot;. The second version
-        encapsulates this loop idiom internally and is generally the preferred
-        method.</p>
-<pre>
-template &lt;typename ScopedLock, typename Pr&gt;
-   void wait(ScopedLock&amp; lock, Pr pred);
-</pre>
-
-        <p><b>Requires:</b> ScopedLock meets the <a href=
-        "lock_concept.html#ScopedLock">ScopedLock</a> requirements, return from
-        <code>pred()</code> convertible to bool.</p>
-
-        <p><b>Effects:</b> As if:</p>
-        <code>&nbsp;&nbsp;&nbsp;while (!pred()) wait(lock)</code> 
-
-        <p><b>Throws:</b> <code><a href="lock_error.html">lock_error</a></code>
-        if <code>!lock.locked()</code></p>
-        <hr>
-
-        <h3>timed_wait</h3>
-<pre>
-template &lt;typename ScopedLock&gt;
-   bool timed_wait(ScopedLock&amp; lock, const <a href=
-"xtime.html">xtime</a>&amp; xt);
-</pre>
-
-        <p><b>Requires:</b> ScopedLock meets the <a href=
-        "lock_concept.html#ScopedLock">ScopedLock</a>
-        requirements.</p>
-
-        <p><b>Effects:</b> Releases the lock on the <a href=
-        "mutex_concept.html">mutex model</a> associated with the <code>
-        lock</code>, blocks the current thread of execution until readied by a
-        call to <code>this-&gt;notify_one()</code> or <code>
-        this-&gt;notify_all()</code>, or until <code>xt</code>, and then
-        reacquires the lock. All effects occur in an atomic fashion.</p>
-
-        <p><b>Throws:</b> <code><a href="lock_error.html">lock_error</a></code>
-        if <code>!lock.locked()</code></p>
-
-        <p><b>Danger:</b> This version should always be used within a loop
-        checking that the state logically associated with the <code>
-        condition</code> has become true. Without the loop, race conditions can
-        ensue due to &quot;spurious wake ups&quot;. The second version
-        encapsulates this loop idiom internally and is generally the preferred
-        method.</p>
-
-        <p><b>Returns:</b> <code>false</code> if <code>xt</code> is reached,
-        otherwise <code>true</code>.</p>
-<pre>
-template &lt;typename ScopedLock, typename Pr&gt;
-   bool timed_wait(ScopedLock&amp; lock, const <a href=
-"xtime.html">xtime</a>&amp; xt, Pr pred);
-</pre>
-
-        <p><b>Requires:</b> ScopedLock meets the <a href=
-        "lock_concept.html#ScopedLock">ScopedLock</a> requirements,
-        return from <code>pred()</code> convertible to bool.</p>
-
-        <p><b>Effects:</b> As if:</p>
-        <code>&nbsp;&nbsp;&nbsp;while (!pred())<br>
-         &nbsp;&nbsp;&nbsp;{<br>
-         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (!timed_wait(lock, xt))<br>
-         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return
-        false;<br>
-         &nbsp;&nbsp;&nbsp;}</code> 
-
-        <p><b>Throws:</b> <code><a href="lock_error.html">lock_error</a></code>
-        if <code>!lock.locked()</code></p>
-
-        <p><b>Returns:</b> <code>false</code> if <code>xt</code> is reached,
-        otherwise <code>true</code>.</p>
-        <hr>
-
-        <h2><a name="Example">Example Usage</a></h2>
-<pre>
-#include &lt;iostream&gt;
-#include &lt;vector&gt;
-#include <a href="../../../boost/utility.hpp">&lt;boost/utility.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/condition.hpp">&lt;boost/thread/condition.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-
-class bounded_buffer : private boost::noncopyable
-{
-public:
-    typedef boost::mutex::scoped_lock lock;
-
-    bounded_buffer(int n) : begin(0), end(0), buffered(0), circular_buf(n) { }
-
-    void send (int m) {
-        lock lk(monitor);
-        while (buffered == circular_buf.size())
-            buffer_not_full.wait(lk);
-        circular_buf[end] = m;
-        end = (end+1) % circular_buf.size();
-        ++buffered;
-        buffer_not_empty.notify_one();
-    }
-    int receive() {
-        lock lk(monitor);
-        while (buffered == 0)
-            buffer_not_empty.wait(lk);
-        int i = circular_buf[begin];
-        begin = (begin+1) % circular_buf.size();
-        --buffered;
-        buffer_not_full.notify_one();
-        return i;
-    }
-
-private:
-    int begin, end, buffered;
-    std::vector&lt;int&gt; circular_buf;
-    boost::condition buffer_not_full, buffer_not_empty;
-    boost::mutex monitor;
-};
-
-bounded_buffer buf(2);
-
-void sender() {
-    int n = 0;
-    while (n &lt; 100) {
-       buf.send(n);
-       std::cout &lt;&lt; &quot;sent: &quot; &lt;&lt; n &lt;&lt; std::endl;
-       ++n;
-    }
-    buf.send(-1);
-}
-
-void receiver() {
-    int n;
-    do {
-       n = buf.receive();
-       std::cout &lt;&lt; &quot;received: &quot; &lt;&lt; n &lt;&lt; std::endl;
-    } while (n != -1); // -1 indicates end of buffer
-}
-
-int main(int, char*[])
-{
-    boost::thread thrd1(&amp;sender);
-    boost::thread thrd2(&amp;receiver);
-    thrd1.join();
-    thrd2.join();
-    return 0;
-}
-</pre>
-
-        <p>Typical output (dependent on scheduling policies) is:</p>
-<pre>
-sent: 0
-sent: 1
-received: 0
-received: 1
-sent: 2
-sent: 3
-received: 2
-received: 3
-sent: 4
-received: 4
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/config.html

@@ -1,97 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, Configuration Information</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Configuration Information</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><b>Boost.Threads</b> uses several configuration macros in <a href=
-        "../../config/config.htm">&lt;boost/config.hpp&gt;</a>. These macros
-        are documented here. Most of the macros are of interest only to
-        developers attempting to provide new implementations of <b>
-        Boost.Threads</b>. The one exception to this is BOOST_HAS_THREADS.</p>
-
-        <table summary="macros" cellspacing="10" width="100%">
-            <tr>
-                <td valign="top"><b>Macro</b> </td>
-
-                <td valign="top"><b>Meaning</b> </td>
-            </tr>
-
-            <tr>
-                <td valign="top">BOOST_HAS_THREADS</td>
-
-                <td valign="top">Indicates that threading support is available.
-                This means both that there is a platform specific
-                implementation for <b>Boost.Threads</b> and that threading
-                support has been enabled in a platform specific manner. For
-                instance, on the Win32 platform there&#39;s an implementation
-                for <b>Boost.Threads</b> but unless the program is compiled
-                against one of the multi-threading runtimes (often determined
-                by the compiler predefining the macro _MT) the
-                BOOST_HAS_THREADS macro remains undefined.</td>
-            </tr>
-
-            <tr>
-                <td valign="top">BOOST_HAS_WINTHREADS</td>
-
-                <td valign="top">Indicates that the platform has the Microsoft
-                Win32 threading libraries, and that they should be used to
-                implement <b>Boost.Threads</b>.</td>
-            </tr>
-
-            <tr>
-                <td valign="top">BOOST_HAS_PTHREADS</td>
-
-                <td valign="top">Indicates that the platform has the POSIX
-                pthreads libraries, and that they should be used to implement
-                <b>Boost.Threads</b>.</td>
-            </tr>
-
-            <tr>
-                <td valign="top">BOOST_HAS_FTIME</td>
-
-                <td valign="top">Indicates that the implementation should use
-                GetSystemTimeAsFileTime() and the FILETIME type to calculate
-                the current time. This is an implementation detail used by
-                boost::detail::getcurtime().</td>
-            </tr>
-
-            <tr>
-                <td valign="top">BOOST_HAS_GETTTIMEOFDAY</td>
-
-                <td valign="top">Indicates that the implementation should use
-                gettimeofday() to calculate the current time. This is an
-                implementation detail used by boost::detail::getcurtime().</td>
-            </tr>
-        </table>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/configuration.xml

@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="thread.configuration" last-revision="$Date$">
+	<title>Configuration</title>
+	<para>&Boost.Threads; uses several configuration macros in &lt;boost/config.hpp&gt;,
+	as well as configuration macros meant to be supplied by the application. These
+	macros are documented here.
+	</para>
+	<section id="thread.configuration.public">
+		<title>Library Defined Public Macros</title>
+		<para>
+	These macros are defined by &Boost.Threads; but are expected to be used
+	by application code.
+		</para>
+		<informaltable>
+			<tgroup cols="2">
+				<thead>
+					<row>
+						<entry>Macro</entry>
+						<entry>Meaning</entry>
+					</row>
+				</thead>
+				<tbody>
+					<row>
+						<entry>BOOST_HAS_THREADS</entry>
+						<entry>
+	Indicates that threading support is available. This means both that there
+	is a platform specific implementation for &Boost.Threads; and that
+	threading support has been enabled in a platform specific manner. For instance,
+	on the Win32 platform there&#39;s an implementation for &Boost.Threads;
+	but unless the program is compiled against one of the multithreading runtimes
+	(often determined by the compiler predefining the macro _MT) the BOOST_HAS_THREADS
+	macro remains undefined.
+						</entry>
+					</row>
+				</tbody>
+			</tgroup>
+		</informaltable>
+	</section>
+	<section id="thread.configuration.implementation">
+		<title>Library Defined Implementation Macros</title>
+		<para>
+	These macros are defined by &Boost.Threads; and are implementation details
+	of interest only to implementors.
+		</para>
+		<informaltable>
+			<tgroup cols="2">
+				<thead>
+					<row>
+						<entry>Macro</entry>
+						<entry>Meaning</entry>
+					</row>
+				</thead>
+				<tbody>
+					<row>
+						<entry>BOOST_HAS_WINTHREADS</entry>
+						<entry>
+	Indicates that the platform has the Microsoft Win32 threading libraries,
+	and that they should be used to implement &Boost.Threads;.
+			            </entry>
+					</row>
+					<row>
+						<entry>BOOST_HAS_PTHREADS</entry>
+						<entry>
+	Indicates that the platform has the POSIX pthreads libraries, and that
+	they should be used to implement &Boost.Threads;.
+						</entry>
+					</row>
+					<row>
+						<entry>BOOST_HAS_FTIME</entry>
+						<entry>
+	Indicates that the implementation should use GetSystemTimeAsFileTime()
+	and the FILETIME type to calculate the current time. This is an implementation
+	detail used by boost::detail::getcurtime().
+						</entry>
+					</row>
+					<row>
+						<entry>BOOST_HAS_GETTTIMEOFDAY</entry>
+						<entry>
+	Indicates that the implementation should use gettimeofday() to calculate
+	the current time. This is an implementation detail used by boost::detail::getcurtime().
+						</entry>
+					</row>
+				</tbody>
+			</tgroup>
+		</informaltable>
+	</section>
+</section>

doc/definitions.html

@@ -1,348 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Language" content="en-us">
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=windows-1252">
-        <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-        <meta name="ProgId" content="FrontPage.Editor.Document">
-
-        <title>Boost.Threads Definitions</title>
-    </head>
-
-    <body bgcolor="#FFFFFF">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Definitions</h2>
-                </td>
-            </tr>
-        </table>
-
-        <h2>Introduction</h2>
-
-        <p>The definitions are given in terms of the <a href=
-        "bibliography.html#ISO-98">C++ Standard</a>. References to the standard
-        are in the form [1.2.3/4], which represents the section number, with
-        the paragraph number following the &quot;/&quot;.</p>
-
-        <p>Because the definitions are written in something akin to
-        &quot;standardese&quot;, they can be difficult to understand. The
-        intent isn&#39;t to confuse, but rather to clarify the additional
-        requirements Boost.Threads places on a C++ implementation as defined by
-        the C++ Standard.</p>
-
-        <h2>Definitions</h2>
-
-        <h3>Thread</h3>
-
-        <p>Thread is short for &quot;thread of execution&quot;. A thread of
-        execution is an execution environment [1.9/7] within the execution
-        environment of a C++ program [1.9]. The main() function [3.6.1] of the
-        program is the initial function of the initial thread. A program in a
-        multi-threading environment always has an initial thread even if the
-        program explicitly creates no additional threads.</p>
-
-        <p>Unless otherwise specified, each thread shares all aspects of its
-        execution environment with other threads in the program. Shared aspects
-        of the execution environment include, but are not limited to, the
-        following:</p>
-
-        <ul>
-            <li>Static storage duration (static, extern) objects [3.7.1].</li>
-        </ul>
-
-        <ul>
-            <li>Dynamic storage duration (heap) objects [3.7.3]. Thus each
-            memory allocation will return a unique addresses, regardless of the
-            thread making the allocation request.</li>
-        </ul>
-
-        <ul>
-            <li>Automatic storage duration (stack) objects [3.7.2] accessed via
-            pointer or reference from another thread.</li>
-        </ul>
-
-        <ul>
-            <li>Resources provided by the operating system. For example,
-            files.</li>
-        </ul>
-
-        <ul>
-            <li>The program itself. In other words, each thread is executing
-            some function of the same program, not a totally different
-            program.</li>
-        </ul>
-
-        <p>Each thread has its own:</p>
-
-        <ul>
-            <li>Registers and current execution sequence (program counter)
-            [1.9/5].</li>
-        </ul>
-
-        <ul>
-            <li>Automatic storage duration (stack) objects [3.7.2].</li>
-        </ul>
-
-        <h3><a name="Thread-safe">Thread-safe</a></h3>
-
-        <p>A program is thread-safe if it has no <a href="#Race condition">race
-        conditions</a>, does not <a href="#Deadlock">deadlock</a>, and has no
-        <a href="#Priority failure">priority failures</a>.</p>
-
-        <p>Note that thread-safety does not necessarily imply efficiency, and
-        than while some thread-safety violations can be determined statically
-        at compile time, many thread-safety errors can only only be detected at
-        runtime.</p>
-
-        <h3>Thread <a name="State">State</a></h3>
-
-        <p>During the lifetime of a thread, it shall be in one of the following
-        states:</p>
-
-        <table summary="thread states" border="1" cellpadding="5">
-            <tr>
-                <td><b>State</b></td>
-
-                <td><b>Description</b></td>
-            </tr>
-
-            <tr>
-                <td>Ready</td>
-
-                <td>Ready to run, but waiting for a processor.</td>
-            </tr>
-
-            <tr>
-                <td>Running</td>
-
-                <td>Currently executing on a processor. Zero or more threads
-                may be running at any time, with a maximum equal to the number
-                of processors.</td>
-            </tr>
-
-            <tr>
-                <td>Blocked</td>
-
-                <td>Waiting for some resource other than a processor which is
-                not currently available, or for the completion of calls to
-                library functions [1.9/6]. The term &quot;waiting&quot; is
-                synonymous for &quot;blocked&quot;</td>
-            </tr>
-
-            <tr>
-                <td>Terminated</td>
-
-                <td>Finished execution but not yet detached or joined.</td>
-            </tr>
-        </table>
-
-        <p>Thread state transitions shall occur only as specified:</p>
-
-        <table summary="state transitions" border="1" cellpadding="5">
-            <tr>
-                <td><b>From</b></td>
-
-                <td><b>To</b></td>
-
-                <td><b>Cause</b></td>
-            </tr>
-
-            <tr>
-                <td>
-                    <p align="left">[none]</p>
-                </td>
-
-                <td>Ready</td>
-
-                <td>Thread is created by a call to a library function. In the
-                case of the initial thread, creation is implicit and occurs
-                during the startup of the main() function [3.6.1].</td>
-            </tr>
-
-            <tr>
-                <td>Ready</td>
-
-                <td>Running</td>
-
-                <td>Processor becomes available.</td>
-            </tr>
-
-            <tr>
-                <td>Running</td>
-
-                <td>Ready</td>
-
-                <td>Thread preempted.</td>
-            </tr>
-
-            <tr>
-                <td>Running</td>
-
-                <td>Blocked</td>
-
-                <td>Thread calls a library function which waits for a resource
-                or for the completion of I/O.</td>
-            </tr>
-
-            <tr>
-                <td>Running</td>
-
-                <td>Terminated</td>
-
-                <td>Thread returns from its initial function, calls a thread
-                termination library function, or is cancelled by some other
-                thread calling a thread termination library function.</td>
-            </tr>
-
-            <tr>
-                <td>Blocked</td>
-
-                <td>Ready</td>
-
-                <td>The resource being waited for becomes available, or the
-                blocking library function completes.</td>
-            </tr>
-
-            <tr>
-                <td>Terminated</td>
-
-                <td>[none]</td>
-
-                <td>Thread is detached or joined by some other thread calling
-                the appropriate library function, or by program termination
-                [3.6.3].</td>
-            </tr>
-        </table>
-
-        <p>[Note: if a suspend() function is added to the threading library,
-        additional transitions to the blocked state will have to be added to
-        the above table.]</p>
-
-        <h3><a name="Race condition">Race condition</a></h3>
-
-        <p>A race condition is what occurs when multiple threads read and write
-        to the same memory without proper synchronization, resulting in an
-        incorrect value being read or written. The result of a race condition
-        may be a bit pattern which isn&#39;t even a valid value for the data
-        type. A race condition results in undefined behavior [1.3.12].</p>
-
-        <p>Race conditions can be prevented by serializing memory access using
-        the tools provided by Boost.Threads.</p>
-
-        <h3><a name="Deadlock">Deadlock</a></h3>
-
-        <p>Deadlock is an execution state where for some set of threads, each
-        thread in the set is blocked waiting for some action by one of the
-        other threads in the set. Since each is waiting on the others, none
-        will ever become ready again.</p>
-
-        <h3><a name="Priority failure">Priority failure</a></h3>
-
-        <p>A priority failure (such as priority inversion or infinite
-        overtaking) occurs when threads executed in such a sequence that
-        required work is not performed in time to be useful.</p>
-
-        <h2>Memory visibility between threads</h2>
-
-        <p>An address [1.7] shall always point to the same memory byte,
-        regardless of the thread or processor dereferencing the address.</p>
-
-        <p>An object [1.8, 1.9] is accessible from multiple threads if it is of
-        static storage duration (static, extern) [3.7.1], or if a pointer or
-        reference to it is explicitly or implicitly dereferenced in multiple
-        threads.</p>
-
-        <p>For an object accessible from multiple threads, the value of the
-        object accessed from one thread may be indeterminate or different than
-        the value accessed from another thread, except under the conditions
-        specified in the following table. For the same row of the table, the
-        value of an object accessible at the indicated sequence point in thread
-        A will be determinate and the same if accessed at or after the
-        indicated sequence point in thread B, provided the object is not
-        otherwise modified. In the table, the &quot;sequence point at a
-        call&quot; is the sequence point after the evaluation of all function
-        arguments [1.9/17], while the &quot;sequence point after a call&quot;
-        is the sequence point after the copying of the returned value...&quot;
-        [1.9/17].</p>
-
-        <table summary="memory visibility" border="1" cellpadding="5">
-            <tr>
-                <td align="center"><b>Thread A</b></td>
-
-                <td align="center"><b>Thread B</b></td>
-            </tr>
-
-            <tr>
-                <td>The sequence point at a call to a library thread-creation
-                function.</td>
-
-                <td>The first sequence point of the initial function in the new
-                thread created by the Thread A call.</td>
-            </tr>
-
-            <tr>
-                <td>The sequence point at a call to a library function which
-                locks a mutex, directly or by waiting for a condition
-                variable.</td>
-
-                <td>The sequence point after a call to a library function which
-                unlocks the same mutex.</td>
-            </tr>
-
-            <tr>
-                <td>The last sequence point before thread termination.</td>
-
-                <td>The sequence point after a call to a library function which
-                joins the terminated thread.</td>
-            </tr>
-
-            <tr>
-                <td>The sequence point at a call to a library function which
-                signals or broadcasts a condition variable.</td>
-
-                <td>The sequence point after the call to the library function
-                which was waiting on that same condition variable or
-                signal.</td>
-            </tr>
-        </table>
-
-        <p>The architecture of the execution environment and the observable
-        behavior of the abstract machine [1.9] shall be the same on all
-        processors.</p>
-
-        <p>The latitude granted by the C++ standard for an implementation to
-        alter the definition of observable behavior of the abstract machine to
-        include additional library I/O functions [1.9/6] is extended to include
-        threading library functions.</p>
-
-        <p>When an exception is thrown and there is no matching exception
-        handler in the same thread, behavior is undefined. The preferred
-        behavior is the same as when there is no matching exception handler in
-        a program [15.3/9]. That is, terminate() is called, and it is
-        implementation defined whether or not the stack is unwound.</p>
-
-        <h2><a name="Acknowledgements">Acknowledgements</a></h2>
-
-        <p>This document has been much improved by the incorporation of
-        comments from William Kempf.</p>
-
-        <p>The visibility rules are based on <a href=
-        "bibliography.html#Butenhof-97">[Butenhof 97]</a>.</p>
-        <hr>
-
-        <p>Revised 
-        <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %b %Y" startspan -->05 Nov 2001<!--webbot bot="Timestamp" endspan i-checksum="15246" --></p>
-
-        <p>&copy; Copyright Beman Dawes, 2001</p>
-    </body>
-</html>
-

doc/design.xml

@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.design" last-revision="$Date$">
+  <title>Design</title>
+  <para>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 concepts unique to C++, such as
+  exceptions.</para>
+  <para>The &Boost.Threads; library is an attempt to define a portable interface
+  for writing parallel processes in C++.</para>
+  <section id="threads.design.goals">
+    <title>Goals</title>
+    <para>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.
+    <variablelist>
+	  <varlistentry>
+	    <term>Portability</term>
+		<listitem>
+          <para>&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.</para>
+		</listitem>
+	  </varlistentry>
+	  <varlistentry>
+        <term>Safety</term>
+        <listitem>
+          <para>&Boost.Threads; was designed to be as safe as possible. Writing
+		  <link linkend="threads.glossary.thread-safe">thread-safe</link>
+		  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:
+          <itemizedlist>
+            <listitem>
+              <para>C++ language features are used to make correct usage easy
+			  (if possible) and error-prone usage impossible or at least more
+			  difficult. For example, see the <link
+			  linkend="threads.concepts.Mutex">Mutex</link> and <link
+			  linkend="threads.concepts.Lock">Lock</link> designs, and note
+			  how they interact.</para>
+            </listitem>
+            <listitem>
+              <para>Certain traditional concurrent programming features are
+			  considered so error-prone that they are not provided at all. For
+			  example, see <xref linkend="threads.rationale.events" />.</para>
+            </listitem>
+            <listitem>
+              <para>Dangerous features, or features which may be misused, are
+              identified as such in the documentation to make users aware of
+              potential pitfalls.</para>
+            </listitem>
+          </itemizedlist></para>
+		</listitem>
+	  </varlistentry>
+      <varlistentry>
+	    <term>Flexibility</term>
+		<listitem>
+		  <para>&Boost.Threads; was designed to be flexible. This goal is often
+		  at odds with <emphasis>safety</emphasis>. 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.</para>
+        </listitem>
+	  </varlistentry>
+      <varlistentry>
+        <term>Efficiency</term>
+		<listitem>
+          <para>&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 <emphasis>safety</emphasis>. Every
+		  effort was made to ensure efficient implementations, but when in
+		  conflict <emphasis>safety</emphasis> has always taken
+		  precedence.</para>
+        </listitem>
+	  </varlistentry>
+    </variablelist></para>
+  </section>
+  <section>
+    <title>Iterative Phases</title>
+    <para>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 it is very difficult to use them safely or to provide formal
+	proofs for constructs built on top of them. There has been a lot of research
+	into other concepts, such as in "Communicating Sequential Processes."
+	&Boost.Threads; was designed in iterative steps, with each step providing 
+	the building blocks necessary for the next step and giving the researcher 
+	the tools necessary to explore new concepts in a portable manner.</para>
+    <para>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.</para>
+  </section>
+  <section>
+    <title>Phase 1, Synchronization Primitives</title>
+    <para>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 therefore 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 <link
+	linkend="threads.glossary.thread-safe">thread-safe</link>
+	implementations. This need far out weighs the need for portable methods to
+	create and manage threads.</para>
+    <para>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
+	<classname>boost::mutex</classname>, 
+	<classname>boost::try_mutex</classname>,
+	<classname>boost::timed_mutex</classname>, 
+	<classname>boost::recursive_mutex</classname>,
+	<classname>boost::recursive_try_mutex</classname>,
+	<classname>boost::recursive_timed_mutex</classname>, and
+	<classname>boost::lock_error</classname>. These are considered the "core"
+	synchronization primitives, though there are others that will be added in
+	later phases.</para>
+  </section>
+  <section id="threads.design.phase2">
+    <title>Phase 2, Thread Management and Thread Specific Storage</title>
+    <para>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 <classname>boost::thread</classname> and
+	<classname>boost::thread_specific_ptr</classname> types. With these
+	additions the &Boost.Threads; library can be considered minimal but
+	complete.</para>
+  </section>
+  <section>
+    <title>The Next Phase</title>
+    <para>The next phase will address more advanced synchronization concepts,
+    such as read/write mutexes and barriers.</para>
+  </section>
+</section>

doc/entities.xml

@@ -0,0 +1,26 @@
+<!ENTITY Boost.Threads "<emphasis role='bold'>Boost.Threads</emphasis>">
+<!ENTITY Boost.Build "<emphasis role='bold'>Boost.Build</emphasis>">
+<!ENTITY cite.AndrewsSchneider83  "<citation><xref
+linkend='threads.bib.AndrewsSchneider83'
+endterm='threads.bib.AndrewsSchneider83.abbrev'/></citation>">
+<!ENTITY cite.Boost "<citation><xref linkend='threads.bib.Boost'
+endterm='threads.bib.Boost.abbrev'/></citation>">
+<!ENTITY cite.Hansen73 "<citation><xref linkend='threads.bib.Hansen73'
+endterm='threads.bib.Hansen73.abbrev'/></citation>">
+<!ENTITY cite.Butenhof97 "<citation><xref linkend='threads.bib.Butenhof97'
+endterm='threads.bib.Butenhof97.abbrev'/></citation>">
+<!ENTITY cite.Hoare74 "<citation><xref linkend='threads.bib.Hoare74'
+endterm='threads.bib.Hoare74.abbrev'/></citation>">
+<!ENTITY cite.ISO98 "<citation><xref linkend='threads.bib.ISO98'
+endterm='threads.bib.ISO98.abbrev'/></citation>">
+<!ENTITY cite.McDowellHelmbold89 "<citation><xref
+linkend='threads.bib.McDowellHelmbold89'
+endterm='threads.bib.McDowellHelmbold89.abbrev'/></citation>">
+<!ENTITY cite.SchmidtPyarali "<citation><xref
+linkend='threads.bib.SchmidtPyarali'
+endterm='threads.bib.SchmidtPyarali.abbrev'/></citation>">
+<!ENTITY cite.SchmidtStalRohnertBuschmann "<citation><xref
+linkend='threads.bib.SchmidtStalRohnertBuschmann'
+endterm='threads.bib.SchmidtStalRohnertBuschmann.abbrev'/></citation>">
+<!ENTITY cite.Stroustrup "<citation><xref linkend='threads.bib.Stroustrup'
+endterm='threads.bib.Stroustrup.abbrev'/></citation>">

doc/exceptions-ref.xml

@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/exceptions.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="lock_error">
+		<purpose>
+			<simpara>The lock_error class defines an exception type thrown
+			to indicate a locking related error has been detected.</simpara>
+		</purpose>
+
+		<description>
+			<simpara>Examples of errors indicated by a lock_error exception 
+			include a lock operation which can be determined to result in a 
+			deadlock, or unlock operations attempted by a thread that does 
+			not own the lock.</simpara>
+		</description>
+
+		<inherit access="public">
+			<type><classname>std::logical_error</classname></type>
+		</inherit>
+
+		<constructor>
+			<effects><simpara>Constructs a <code>lock_error</code> object.
+			</simpara></effects>
+		</constructor>
+	</class>
+
+	<class name="thread_resource_error">
+		<purpose>
+			<simpara>The <classname>thread_resource_error</classname> class
+			defines an exception type that is thrown by constructors in the
+			&Boost.Threads; library when thread-related resources can not be 
+			acquired.</simpara>
+		</purpose>
+
+		<description>
+			<simpara><classname>thread_resource_error</classname> is used
+			only when thread-related resources cannot be acquired; memory
+			allocation failures are indicated by 
+			<classname>std::bad_alloc</classname>.</simpara>
+		</description>
+
+		<inherit access="public">
+			<type><classname>std::runtime_error</classname></type>
+		</inherit>
+
+		<constructor>
+			<effects><simpara>Constructs a <code>thread_resource_error</code>
+			object.</simpara></effects>
+		</constructor>
+	</class>
+  </namespace>
+</header>

doc/faq.html

@@ -1,193 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, FAQ</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width="277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Frequently Asked Questions</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <h2>1. Are lock objects <a href="definitions.html#Thread-safe">
-        thread-safe</a>?</h2>
-
-        <p><b>No!</b> Lock objects are not meant to be shared between threads.
-        They are meant to be short lived objects created on automatic storage
-        within a code block. Any other usage is just likely to lead to errors
-        and won&#39;t really be of actual benefit any way. Share <a href=
-        "mutex_concept.html">mutexes</a>, not locks. For more information see
-        the <a href="rationale.html#lock_objects">rationale</a> behind the
-        design for lock objects.</p>
-
-        <h2>2a. Why was Boost.Threads modeled after (specific library
-        name)?</h2>
-
-        <p>It wasn&#39;t. Boost.Threads was designed from scratch. Extensive
-        design discussions involved numerous people representing a wide range
-        of experience across many platforms. To ensure portability, the initial
-        implements were done in parallel using POSIX Threads and theWin32
-        threading API. But the Boost.Threads design is very much in the spirit
-        of C++, and thus doesn&#39;t model such C based APIs.</p>
-
-        <h2>2b. Why wasn&#39;t Boost.Threads modeled after (specific library
-        name)?</h2>
-
-        <p>Existing C++ libraries either seemed dangerous (often failing to
-        take advantage of prior art to reduce errors) or had excessive
-        dependencies on library components unrelated to threading. Existing C
-        libraries couldn&#39;t meet our C++ requirements, and were also missing
-        certain features. For instance, the WIN32 thread API lacks condition
-        variables, even though these are critical for the important Monitor
-        pattern <a href="bibliography.html#Schmidt-00">[Schmidt 00]</a>.</p>
-
-        <h2>3. Why do <a href="mutex_concept.html">Mutexes</a> have noncopyable
-        semantics?</h2>
-
-        <p>To ensure that <a href="definitions.html#Deadlock">deadlocks</a>
-        don&#39;t occur. The only logical form of copy would be to use some
-        sort of shallow copy semantics in which multiple mutex objects could
-        refer to the same mutex state. This means that if ObjA has a mutex
-        object as part of its state and ObjB is copy constructed from it, then
-        when ObjB::foo() locks the mutex it has effectively locked ObjA as
-        well. This behavior can result in deadlock. Other copy semantics result
-        in similar problems (if you think you can prove this to be wrong then
-        supply us with an alternative and we&#39;ll reconsider).</p>
-
-        <h2>4. How can you prevent <a href="definitions.html#Deadlock">
-        deadlock</a> from occurring when a thread must lock multiple
-        mutexes?</h2>
-
-        <p>Always lock them in the same order. One easy way of doing this is to
-        use each mutex&#39;s address to determine the order in which they are
-        locked. A future Boost.Threads concept may wrap this pattern up in a
-        reusable class.</p>
-
-        <h2>5. Don&#39;t noncopyable <a href="mutex_concept.html">mutex</a>
-        semantics mean that a class with a mutex member will be noncopyable as
-        well?</h2>
-
-        <p>No, but what it does mean is that the compiler can&#39;t generate a
-        copy constructor and assignment operator, so they will have to be coded
-        explicitly. This is a <b>good thing</b>, however, since the compiler
-        generated operations would not be <a href=
-        "definitions.html#Thread-safe">thread-safe</a>. The following is a
-        simple example of a class with copyable semantics and internal
-        synchronization through a mutex member.</p>
-<pre>
-class counter
-{
-public:
-   // Doesn't need synchronization since there can be no references to *this
-   // until after it's constructed!
-   explicit counter(int initial_value)
-      : m_value(initial_value)
-   {
-   }
-   
-   // We only need to syncronize other for the same reason we don't have to
-   // synchronize on construction!
-   counter(const counter&amp; other)
-   {
-      boost::mutex::scoped_lock scoped_lock(other.m_mutex);
-      m_value = other.m_value;
-   }
-   
-   // For assignment we need to synchronize both objects!
-   const counter&amp; operator=(const counter&amp; other)
-   {
-      if (this == &amp;other)
-         return *this;
-         
-      boost::mutex::scoped_lock lock1(&amp;m_mutex &lt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
-      boost::mutex::scoped_lock lock2(&amp;m_mutex &gt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
-      m_value = other.m_value;
-      
-      return *this;
-   }
-   
-   int value() const
-   {
-      boost::mutex::scoped_lock scoped_lock(m_mutex);
-      return m_value;
-   }
-   int increment()
-   {
-      boost::mutex::scoped_lock scoped_lock(m_mutex);
-      return ++m_value;
-   }
-   
-private:
-   mutable boost::mutex m_mutex;
-   int m_value;
-};
-</pre>
-
-        <h2>6. How can you lock a <a href="mutex_concept.html">mutex</a> member
-        in a const member function, in order to implement the Monitor
-        Pattern?</h2>
-
-        <p>The Monitor Pattern mutex <a href="bibliography.html#Schmidt-00">
-        [Schmidt 00]</a> should simply be declared as mutable. See the example
-        code above. The internal state of mutex types could have been made
-        mutable, with all lock calls made via const functions, but this does a
-        poor job of documenting the actual semantics. Declaring a mutex member
-        as mutable clearly documentations the intended semantics.</p>
-
-        <h2>7. Why supply <a href="condition.html">condition variables</a>
-        rather than <a href="rationale.html#Events">event variables</a>?</h2>
-
-        <p>Condition variables result in user code much less prone to <a href=
-        "definitions.html#Race condition">race conditions</a> than event
-        variables. See <a href="rationale.html#Events">Rationale</a> for
-        analysis. Also see <a href="bibliography.html#Hoare-74">[Hoare74]</a>
-        and <a href="bibliography.html#Schmidt-00">[Schmidt 00]</a>.</p>
-
-        <h2>8. Why isn&#39;t thread cancellation or termination provided?</h2>
-
-        <p>There&#39;s a valid need for thread termination, so at some point
-        Boost.Threads probably will include it, but only after we can find a
-        truly safe (and portable) mechanism for this concept.</p>
-
-        <h2>9. Is it safe for threads to share automatic storage duration
-        (stack) objects via pointers or references?</h2>
-
-        <p>Only if you can guarantee that the lifetime of the stack object will
-        not end while other threads might still access the object. Thus the
-        safest practice is to avoid sharing stack objects, particularly in
-        designs where threads are created and destroyed dynamically. Restrict
-        sharing of stack objects to simple designs with very clear and
-        unchanging function and thread lifetimes. (Suggested by Darryl
-        Green).</p>
-
-        <h2>10. Why has class semaphore disappeared?</h2>
-
-        <p>Semaphore was removed as too error prone. The same effect can be
-        achieved with greater safety by the combination of a mutex and a
-        condition variable.</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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/faq.xml

@@ -0,0 +1,210 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.faq" last-revision="$Date$">
+  <title>Frequently Asked Questions</title>
+  <qandaset>
+    <qandaentry>
+	  <question>
+	    <para>Are lock objects <link
+		linkend="threads.glossary.thread-safe">thread safe</link>?</para>
+	  </question>
+	  <answer>
+	    <para><emphasis role="bold">No!</emphasis> Lock objects are not meant to
+		be shared between threads. They are meant to be short-lived objects
+		created on automatic storage within a code block. Any other usage is
+		just likely to lead to errors and won't really be of actual benefit anyway.
+		Share <link linkend="threads.concepts.mutexes">Mutexes</link>, not
+		Locks. For more information see the <link
+		linkend="threads.rationale.locks">rationale</link> behind the
+		design for lock objects.</para>
+	  </answer>
+	</qandaentry>
+    <qandaentry>
+      <question>
+	    <para>Why was &Boost.Threads; modeled after (specific library
+		name)?</para>
+	  </question>
+	  <answer>
+	    <para>It wasn't. &Boost.Threads; was designed from scratch. Extensive
+		design discussions involved numerous people representing a wide range of
+		experience across many platforms. To ensure portability, the initial
+		implements were done in parallel using POSIX Threads and the Win32
+		threading API. But the &Boost.Threads; design is very much in the spirit
+		of C++, and thus doesn't model such C based APIs.</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Why wasn't &Boost.Threads; modeled after (specific library
+	    name)?</para>
+	  </question>
+	  <answer>
+        <para>Existing C++ libraries either seemed dangerous (often failing to
+		take advantage of prior art to reduce errors) or had excessive
+		dependencies on library components unrelated to threading. Existing C
+		libraries couldn't meet our C++ requirements, and were also missing
+		certain features. For instance, the WIN32 thread API lacks condition
+		variables, even though these are critical for the important Monitor
+		pattern &cite.SchmidtStalRohnertBuschmann;.</para>
+      </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Why do <link linkend="threads.concepts.mutexes">Mutexes</link>
+		have noncopyable semantics?</para>
+	  </question>
+	  <answer>
+        <para>To ensure that <link
+		linkend="threads.glossary.deadlock">deadlocks</link> don't occur. The
+		only logical form of copy would be to use some sort of shallow copy
+		semantics in which multiple mutex objects could refer to the same mutex
+		state. This means that if ObjA has a mutex object as part of its state
+		and ObjB is copy constructed from it, then when ObjB::foo() locks the
+		mutex it has effectively locked ObjA as well. This behavior can result
+		in deadlock. Other copy semantics result in similar problems (if you
+		think you can prove this to be wrong then supply us with an alternative
+		and we'll reconsider).</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>How can you prevent <link
+		linkend="threads.glossary.deadlock">deadlock</link> from occurring when
+		a thread must lock multiple mutexes?</para>
+	  </question>
+	  <answer>
+	    <para>Always lock them in the same order. One easy way of doing this is
+		to use each mutex's address to determine the order in which they are
+		locked. A future &Boost.Threads; concept may wrap this pattern up in a
+		reusable class.</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Don't noncopyable <link
+		linkend="threads.concepts.mutexes">Mutex</link> semantics mean that a
+		class with a mutex member will be noncopyable as well?</para>
+	  </question>
+	  <answer>
+	    <para>No, but what it does mean is that the compiler can't generate a
+		copy constructor and assignment operator, so they will have to be coded
+		explicitly. This is a <emphasis role="bold">good thing</emphasis>,
+		however, since the compiler generated operations would not be <link
+		linkend="threads.glossary.thread-safe">thread-safe</link>. The following
+		is a simple example of a class with copyable semantics and internal
+        synchronization through a mutex member.</para>
+<programlisting>
+class counter
+{
+public:
+   // Doesn't need synchronization since there can be no references to *this
+   // until after it's constructed!
+   explicit counter(int initial_value)
+      : m_value(initial_value)
+   {
+   }
+   // We only need to synchronize other for the same reason we don't have to
+   // synchronize on construction!
+   counter(const counter&amp; other)
+   {
+      boost::mutex::scoped_lock scoped_lock(other.m_mutex);
+      m_value = other.m_value;
+   }
+   // For assignment we need to synchronize both objects!
+   const counter&amp; operator=(const counter&amp; other)
+   {
+      if (this == &amp;other)
+         return *this;
+      boost::mutex::scoped_lock lock1(&amp;m_mutex &lt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
+      boost::mutex::scoped_lock lock2(&amp;m_mutex &gt; &amp;other.m_mutex ? m_mutex : other.m_mutex);
+      m_value = other.m_value;
+      return *this;
+   }
+   int value() const
+   {
+      boost::mutex::scoped_lock scoped_lock(m_mutex);
+      return m_value;
+   }
+   int increment()
+   {
+      boost::mutex::scoped_lock scoped_lock(m_mutex);
+      return ++m_value;
+   }
+private:
+   mutable boost::mutex m_mutex;
+   int m_value;
+};
+</programlisting>
+      </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>How can you lock a <link
+		linkend="threads.concepts.mutexes">Mutex</link> member in a const member
+		function, in order to implement the Monitor Pattern?</para>
+	  </question>
+	  <answer>
+	    <para>The Monitor Pattern &cite.SchmidtStalRohnertBuschmann; mutex
+		should simply be declared as mutable. See the example code above. The
+		internal state of mutex types could have been made mutable, with all
+		lock calls made via const functions, but this does a poor job of
+		documenting the actual semantics (and in fact would be incorrect since
+		the logical state of a locked mutex clearly differs from the logical
+		state of an unlocked mutex). Declaring a mutex member as mutable clearly
+		documents the intended semantics.</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Why supply <classname>boost::condition</classname> variables rather than
+		event variables?</para>
+	  </question>
+	  <answer>
+	    <para>Condition variables result in user code much less prone to <link
+		linkend="threads.glossary.race-condition">race conditions</link> than
+		event variables. See <xref linkend="threads.rationale.events" /> 
+		for analysis. Also see &cite.Hoare74; and &cite.SchmidtStalRohnertBuschmann;.
+		</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Why isn't thread cancellation or termination provided?</para>
+	  </question>
+	  <answer>
+	    <para>There's a valid need for thread termination, so at some point
+		&Boost.Threads; probably will include it, but only after we can find a
+		truly safe (and portable) mechanism for this concept.</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Is it safe for threads to share automatic storage duration (stack)
+		objects via pointers or references?</para>
+	  </question>
+	  <answer>
+	    <para>Only if you can guarantee that the lifetime of the stack object
+		will not end while other threads might still access the object. Thus the
+		safest practice is to avoid sharing stack objects, particularly in
+		designs where threads are created and destroyed dynamically. Restrict
+		sharing of stack objects to simple designs with very clear and
+		unchanging function and thread lifetimes. (Suggested by Darryl
+		Green).</para>
+	  </answer>
+	</qandaentry>
+	<qandaentry>
+	  <question>
+	    <para>Why has class semaphore disappeared?</para>
+	  </question>
+	  <answer>
+	    <para>Semaphore was removed as too error prone. The same effect can be
+		achieved with greater safety by the combination of a mutex and a
+		condition variable.</para>
+	  </answer>
+	</qandaentry>
+  </qandaset>
+</section>

doc/glossary.xml

@@ -0,0 +1,300 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<glossary id="threads.glossary" last-revision="$Date$">
+  <title>Glossary</title>
+  <para>Definitions are given in terms of the C++ Standard
+  &cite.ISO98;. References to the standard are in the form [1.2.3/4], which
+  represents the section number, with the paragraph number following the
+  "/".</para>
+  <para>Because the definitions are written in something akin to "standardese",
+  they can be difficult to understand. The intent isn't to confuse, but rather
+  to clarify the additional requirements &Boost.Threads; places on a C++
+  implementation as defined by the C++ Standard.</para>
+  <glossentry id="threads.glossary.thread">
+    <glossterm>Thread</glossterm>
+    <glossdef>
+	  <para>Thread is short for "thread of execution". A thread of execution is
+	  an execution environment [1.9/7] within the execution environment of a C++
+	  program [1.9]. The main() function [3.6.1] of the program is the initial
+	  function of the initial thread. A program in a multithreading environment
+	  always has an initial thread even if the program explicitly creates no
+	  additional threads.</para>
+      <para>Unless otherwise specified, each thread shares all aspects of its
+	  execution environment with other threads in the program. Shared aspects of
+	  the execution environment include, but are not limited to, the
+	  following:</para>
+	  <itemizedlist>
+        <listitem><para>Static storage duration (static, extern) objects
+		[3.7.1].</para></listitem>
+	    <listitem><para>Dynamic storage duration (heap) objects [3.7.3]. Thus
+		each memory allocation will return a unique addresses, regardless of the
+		thread making the allocation request.</para></listitem>
+        <listitem><para>Automatic storage duration (stack) objects [3.7.2]
+		accessed via pointer or reference from another thread.</para></listitem>
+        <listitem><para>Resources provided by the operating system. For example,
+		files.</para></listitem>
+        <listitem><para>The program itself. In other words, each thread is
+		executing some function of the same program, not a totally different
+		program.</para></listitem>
+      </itemizedlist>
+      <para>Each thread has its own:</para>
+      <itemizedlist>
+        <listitem><para>Registers and current execution sequence (program
+		counter) [1.9/5].</para></listitem>
+        <listitem><para>Automatic storage duration (stack) objects
+		[3.7.2].</para></listitem>
+      </itemizedlist>
+    </glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.thread-safe">
+    <glossterm>Thread-safe</glossterm>
+	<glossdef>
+      <para>A program is thread-safe if it has no <link
+	  linkend="threads.glossary.race-condition">race conditions</link>, does
+	  not <link linkend="threads.glossary.deadlock">deadlock</link>, and has
+	  no <link linkend="threads.glossary.priority-failure">priority
+	  failures</link>.</para>
+	  <para>Note that thread-safety does not necessarily imply efficiency, and
+	  than while some thread-safety violations can be determined statically at
+	  compile time, many thread-safety errors can only only be detected at
+	  runtime.</para>
+	</glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.thread-state">
+    <glossterm>Thread State</glossterm>
+	<glossdef>
+      <para>During the lifetime of a thread, it shall be in one of the following
+	  states:</para>
+	  <table>
+		<title>Thread States</title>
+		<tgroup cols="2" align="left">
+			<thead>
+				<row>
+					<entry>State</entry>
+					<entry>Description</entry>
+				</row>
+			</thead>
+			<tbody>
+				<row>
+					<entry>Ready</entry>
+					<entry>Ready to run, but waiting for a processor.</entry>
+				</row>
+				<row>
+					<entry>Running</entry>
+					<entry>Currently executing on a processor. Zero or more threads
+					may be running at any time, with a maximum equal to the number of
+					processors.</entry>
+				</row>
+				<row>
+					<entry>Blocked</entry>
+					<entry>Waiting for some resource other than a processor which is
+					not currently available, or for the completion of calls to library
+					functions [1.9/6]. The term "waiting" is synonymous with
+					"blocked"</entry>
+				</row>
+				<row>
+					<entry>Terminated</entry>
+					<entry>Finished execution but not yet detached or joined.</entry>
+				</row>
+			</tbody>
+		</tgroup>
+	  </table>
+      <para>Thread state transitions shall occur only as specified:</para>
+	  <table>
+		<title>Thread States Transitions</title>
+		<tgroup cols="3" align="left">
+			<thead>
+				<row>
+					<entry>From</entry>
+					<entry>To</entry>
+					<entry>Cause</entry>
+				</row>
+			</thead>
+			<tbody>
+				<row>
+					<entry>[none]</entry>
+					<entry>Ready</entry>
+					<entry><para>Thread is created by a call to a library function. 
+					In the case of the initial thread, creation is implicit and 
+					occurs during the startup of the main() function [3.6.1].</para></entry>
+				</row>
+				<row>
+					<entry>Ready</entry>
+					<entry>Running</entry>
+					<entry><para>Processor becomes available.</para></entry>
+				</row>
+				<row>
+					<entry>Running</entry>
+					<entry>Ready</entry>
+					<entry>Thread preempted.</entry>
+				</row>
+				<row>
+					<entry>Running</entry>
+					<entry>Blocked</entry>
+					<entry>Thread calls a library function which waits for a resource or
+					for the completion of I/O.</entry>
+				</row>
+				<row>
+					<entry>Running</entry>
+					<entry>Terminated</entry>
+					<entry>Thread returns from its initial function, calls a thread
+					termination library function, or is canceled by some other thread
+					calling a thread termination library function.</entry>
+				</row>
+				<row>
+					<entry>Blocked</entry>
+					<entry>Ready</entry>
+					<entry>The resource being waited for becomes available, or the
+					blocking library function completes.</entry>
+				</row>
+				<row>
+					<entry>Terminated</entry>
+					<entry>[none]</entry>
+					<entry>Thread is detached or joined by some other thread calling the
+					appropriate library function, or by program termination
+					[3.6.3].</entry>
+				</row>
+			</tbody>
+		</tgroup>
+      </table>
+      <para>[Note: if a suspend() function is added to the threading library,
+	  additional transitions to the blocked state will have to be added to the
+	  above table.]</para>
+    </glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.race-condition">
+    <glossterm>Race Condition</glossterm>
+	<glossdef>
+      <para>A race condition is what occurs when multiple threads read from and write
+	  to the same memory without proper synchronization, resulting in an incorrect
+	  value being read or written. The result of a race condition may be a bit
+	  pattern which isn't even a valid value for the data type. A race condition
+	  results in undefined behavior [1.3.12].</para>
+      <para>Race conditions can be prevented by serializing memory access using
+	  the tools provided by &Boost.Threads;.</para>
+    </glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.deadlock">
+    <glossterm>Deadlock</glossterm>
+	<glossdef>
+      <para>Deadlock is an execution state where for some set of threads, each
+	  thread in the set is blocked waiting for some action by one of the other
+	  threads in the set. Since each is waiting on the others, none will ever
+	  become ready again.</para>
+	</glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.starvation">
+    <glossterm>Starvation</glossterm>
+	<glossdef>
+	  <para>The condition in which a thread is not making sufficient progress in
+	  its work during a given time interval.</para>
+	</glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.priority-failure">
+    <glossterm>Priority Failure</glossterm>
+	<glossdef>
+	  <para>A priority failure (such as priority inversion or infinite overtaking)
+	  occurs when threads are executed in such a sequence that required work is not
+	  performed in time to be useful.</para>
+	</glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.undefined-behavior">
+    <glossterm>Undefined Behavior</glossterm>
+	<glossdef>
+	  <para>The result of certain operations in &Boost.Threads; is undefined;
+	  this means that those operations can invoke almost any behavior when
+	  they are executed.</para>
+	  
+	  <para>An operation whose behavior is undefined can work "correctly"
+	  in some implementations (i.e., do what the programmer thought it
+	  would do), while in other implementations it may exhibit almost
+	  any "incorrect" behavior--such as returning an invalid value,
+	  throwing an exception, generating an access violation, or terminating 
+	  the process.</para>
+	  
+	  <para>Executing a statement whose behavior is undefined is a
+	  programming error.</para>
+	</glossdef>
+  </glossentry>
+  <glossentry id="threads.glossary.memory-visibility">
+    <glossterm>Memory Visibility</glossterm>
+	<glossdef>
+	  <para>An address [1.7] shall always point to the same memory byte,
+	  regardless of the thread or processor dereferencing the address.</para>
+      <para>An object [1.8, 1.9] is accessible from multiple threads if it is of
+	  static storage duration (static, extern) [3.7.1], or if a pointer or
+	  reference to it is explicitly or implicitly dereferenced in multiple
+	  threads.</para>
+	  <para>For an object accessible from multiple threads, the value of the
+	  object accessed from one thread may be indeterminate or different from the
+	  value accessed from another thread, except under the conditions specified in
+	  the following table. For the same row of the table, the value of an object
+	  accessible at the indicated sequence point in thread A will be determinate
+	  and the same if accessed at or after the indicated sequence point in thread
+	  B, provided the object is not otherwise modified. In the table, the
+	  "sequence point at a call" is the sequence point after the evaluation of all
+	  function arguments [1.9/17], while the "sequence point after a call" is the
+	  sequence point after the copying of the returned value... [1.9/17].</para>
+      <table>
+		<title>Memory Visibility</title>
+		<tgroup cols="2">
+			<thead>
+				<row>
+					<entry>Thread A</entry>
+					<entry>Thread B</entry>
+				</row>
+			</thead>
+			<tbody>
+				<row>
+					<entry>The sequence point at a call to a library thread-creation
+					function.</entry>
+					<entry>The first sequence point of the initial function in the new
+					thread created by the Thread A call.</entry>
+				</row>
+				<row>
+					<entry>The sequence point at a call to a library function which
+					locks a mutex, directly or by waiting for a condition
+					variable.</entry>
+					<entry>The sequence point after a call to a library function which
+					unlocks the same mutex.</entry>
+				</row>
+				<row>
+					<entry>The last sequence point before thread termination.</entry>
+					<entry>The sequence point after a call to a library function which
+					joins the terminated thread.</entry>
+				</row>
+				<row>
+					<entry>The sequence point at a call to a library function which
+					signals or broadcasts a condition variable.</entry>
+					<entry>The sequence point after the call to the library function
+					which was waiting on that same condition variable or signal.</entry>
+				</row>
+			</tbody>
+		</tgroup>
+      </table>
+      <para>The architecture of the execution environment and the observable
+	  behavior of the abstract machine [1.9] shall be the same on all
+	  processors.</para>
+	  <para>The latitude granted by the C++ standard for an implementation to
+	  alter the definition of observable behavior of the abstract machine to
+	  include additional library I/O functions [1.9/6] is extended to include
+	  threading library functions.</para>
+	  <para>When an exception is thrown and there is no matching exception handler
+	  in the same thread, behavior is undefined. The preferred behavior is the
+	  same as when there is no matching exception handler in a program
+	  [15.3/9]. That is, terminate() is called, and it is implementation-defined
+	  whether or not the stack is unwound.</para>
+    </glossdef>
+  </glossentry>
+  <section>
+    <title>Acknowledgements</title>
+    <para>This document was originally written by Beman Dawes, and then much
+	improved by the incorporation of comments from William Kempf, who now
+	maintains the contents.</para>
+	<para>The visibility rules are based on &cite.Butenhof97;.</para>
+  </section>
+</glossary>

doc/implementation_notes.xml

@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.implementation_notes" last-revision="$Date$">
+	<title>Implementation Notes</title>
+	<section id="threads.implementation_notes.win32">
+		<title>Win32</title>
+		<para>
+			In the current Win32 implementation, creating a boost::thread object
+			during dll initialization will result in deadlock because the thread 
+			class constructor causes the current thread to wait on the thread that 
+			is being created until it signals that it has finished its initialization, 
+			and, as stated in the
+			<ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp">MSDN Library, "DllMain" article, "Remarks" section</ulink>,
+			"Because DLL notifications are serialized, entry-point functions should not
+			attempt to communicate with other threads or processes. Deadlocks may occur as a result."
+			(Also see <ulink url="http://www.microsoft.com/msj/archive/S220.aspx">"Under the Hood", January 1996</ulink> 
+			for a more detailed discussion of this issue).
+		</para>
+		<para>
+			The following non-exhaustive list details some of the situations that
+			should be avoided until this issue can be addressed:
+			<itemizedlist>
+				<listitem>Creating a boost::thread object in DllMain() or in any function called by it.</listitem>
+				<listitem>Creating a boost::thread object in the constructor of a global static object or in any function called by one.</listitem>
+				<listitem>Creating a boost::thread object in MFC's CWinApp::InitInstance() function or in any function called by it.</listitem>
+				<listitem>Creating a boost::thread object in the function pointed to by MFC's _pRawDllMain function pointer or in any function called by it.</listitem>
+			</itemizedlist>
+		</para>
+	</section>
+</section>

doc/index.html

@@ -1,138 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, Index</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Documentation Map</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <h2>Contents</h2>
-
-        <ul>
-            <li><a href="overview.html">Overview</a></li>
-
-            <li>
-                <a href="mutex_concept.html">Mutex Concepts</a> 
-
-                <ul>
-                    <li><a href="mutex_concept.html#Mutex">Mutex</a></li>
-
-                    <li><a href="mutex_concept.html#TryMutex">TryMutex</a></li>
-
-                    <li><a href="mutex_concept.html#TimedMutex">
-                    TimedMutex</a></li>
-                </ul>
-            </li>
-
-            <li>
-                Mutex Classes 
-
-                <ul>
-                    <li><a href="mutex.html">mutex / try_mutex /
-                    timed_mutex</a></li>
-
-                    <li><a href="recursive_mutex.html">recursive_mutex /
-                    recursive_try_mutex / recursive_timed_mutex</a></li>
-                </ul>
-            </li>
-
-            <li>
-                <a href="lock_concept.html">Lock Concepts</a> 
-
-                <ul>
-                    <li><a href="lock_concept.html#Lock">Lock</a></li>
-
-                    <li><a href="lock_concept.html#ScopedLock">
-                    ScopedLock</a></li>
-
-                    <li><a href="lock_concept.html#ScopedTryLock">
-                    ScopedTryLock</a></li>
-
-                    <li><a href="lock_concept.html#ScopedTimedLock">
-                    ScopedTimedLock</a></li>
-                </ul>
-            </li>
-
-            <li>
-                Lock Classes 
-
-                <ul>
-                    <li><a href="scoped_lock.html">scoped_lock</a></li>
-
-                    <li><a href="scoped_try_lock.html">scoped_try_lock</a></li>
-
-                    <li><a href="scoped_timed_lock.html">
-                    scoped_timed_lock</a></li>
-                </ul>
-            </li>
-
-            <li>Class <a href="condition.html">condition</a></li>
-
-            <li>Class <a href="thread_specific_ptr.html">
-            thread_specific_ptr</a></li>
-
-            <li>Class <a href="thread.html">thread</a></li>
-
-            <li>Class <a href="thread_group.html">thread_group</a></li>
-
-            <li>Class <a href="xtime.html">xtime</a></li>
-
-            <li>Class <a href="lock_error.html">lock_error</a></li>
-
-            <li>Class <a href="thread_resource_error.html">
-            thread_resource_error</a></li>
-
-            <li>Routine <a href="call_once.html">call_once</a></li>
-
-            <li><a href="config.html">Configuration Information</a></li>
-
-            <li><a href="introduction.html">Introduction to design</a></li>
-
-            <li><a href="rationale.html">Rationale for design
-            decisions</a></li>
-
-            <li><a href="definitions.html">Definitions</a></li>
-
-            <li><a href="faq.html">Frequently Asked Questions</a></li>
-
-            <li><a href="bibliography.html">Bibliography</a></li>
-
-            <li><a href="acknowledgements.html">Acknowledgements</a></li>
-        </ul>
-        <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>&copy; <i>Copyright <a href="mailto:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001</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>
-

doc/introduction.html

@@ -1,194 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, Introduction</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Introduction</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <h3>Motivation</h3>
-
-        <p>With client/server and three-tier architectures becoming common
-        place in today&#39;s world, it&#39;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++&#39;s
-        strengths, or to address C++&#39;s issues.</p>
-
-        <p>The <b>Boost.Threads</b> library is an attempt to define a portable
-        interface for writing parallel processes in C++.</p>
-
-        <h3>Goals</h3>
-
-        <p>The <b>Boost.Threads</b> 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.</p>
-
-        <ul>
-            <li>
-                <b>Portability</b> 
-
-                <p><b>Boost.Threads</b> 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.</p>
-            </li>
-
-            <li>
-                <b>Safety</b> 
-
-                <p><b>Boost.Threads</b> was designed to be as safe as possible.
-                Writing <a href="definitions.html#Thread-safe">thread-safe</a>
-                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:</p>
-
-                <ul>
-                    <li>
-                        <p align="left">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 <a href="mutex_concept.html">Mutex</a>
-                        and <a href="lock_concept.html">Lock</a> designs, and
-                        how note how they interact.</p>
-                    </li>
-
-                    <li>
-                        <p align="left">Certain traditional concurrent
-                        programming features are considered so error-prone that
-                        they are not provided at all. For example, see the <a
-                        href="rationale.html#Events">Events Not Provided</a>
-                        rationale.</p>
-                    </li>
-
-                    <li>
-                        <p align="left">Dangerous features, or features which
-                        may be misused, are identified as such in the
-                        documentation to make users aware of potential
-                        pitfalls.</p>
-                    </li>
-                </ul>
-            </li>
-
-            <li>
-                <b>Flexibility</b> 
-
-                <p><b>Boost.Threads</b> was designed to be flexible. This goal
-                is often at odds with <i>safety</i>. When functionality might
-                be compromised by the desire to keep the interface safe, <b>
-                Boost.Threads</b> has been designed to provide the
-                functionality, but to make it&#39;s use prohibitive for general
-                use.</p>
-            </li>
-
-            <li>
-                <b>Efficiency</b> 
-
-                <p><b>Boost.Threads</b> 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 &quot;native&quot; API that programmers are inclined
-                to ignore the higher level API. <b>Boost.Threads</b> 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 <i>safety</i>. Every effort was
-                made to ensure efficient implementations, but when in conflict
-                <i>safety</i> has always taken precedence.</p>
-            </li>
-        </ul>
-
-        <h3>Iterative Phases</h3>
-
-        <p>Another goal of <b>Boost.Threads</b> 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. Until
-        recently, these primitives were &quot;state of the art&quot; and the
-        only concepts available to programmers. Recently there has been a lot
-        of research in other concepts, such as in &quot;Communicating
-        Sequential Processes.&quot; <b>Boost.Threads</b> 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.</p>
-
-        <p>Given the goal of following a dynamic, iterative approach <b>
-        Boost.Threads</b> shall go through several growth cycles. Each phase in
-        its development shall be roughly documented here.</p>
-
-        <h4>Phase 1, Synchronization Primitives</h4>
-
-        <p>Boost is all about providing high quality libraries with
-        implementations for many platforms. Unfortunately, there&#39;s a big
-        problem faced by developers wishing to supply such high quality
-        libraries, namely thread-safety. The C++ standard doesn&#39;t address
-        threads at all, but real world programs often make use of native
-        threading support. A portable library that doesn&#39;t address the
-        issue of thread-safety is there for not much help to a programmer who
-        wants to use the library in his multi-threaded application. So
-        there&#39;s a very great need for portable primitives that will allow
-        the library developer to create <a href="definitions.html#Thread-safe">
-        thread-safe</a> implementations. This need far out weighs the need for
-        portable methods to create and manage threads.</p>
-
-        <p>Because of this need, the first phase of <b>Boost.Threads</b>
-        focuses solely on providing portable primitive concepts for thread
-        synchronization. Types provided in this phase include the <a href="mutex.html">
-        mutex/try_mutex/timed_mutex</a>, <a href="recursive_mutex.html">
-        recursive_mutex/recursive_try_mutex/recursive_timed_mutex</a>, <a href=
-        "scoped_lock.html">scoped_lock</a>, <a href="scoped_try_lock.html">
-        scoped_try_lock</a>, <a href="scoped_timed_lock.html">
-        scoped_timed_lock</a> and <a href="lock_error.html">lock_error</a>.
-        These are considered the &quot;core&quot; synchronization primitives,
-        though there are others that will be added in later phases.</p>
-
-        <h4>Phase 2, Thread Management and Thread Specific Storage</h4>
-
-        <p>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 multi-threaded program. Later
-        phases are likely to add additional functionality in this area. This
-        phase of <b>Boost.Threads</b> adds the <a href="thread.html">thread</a>
-        and <a href="thread_specific_ptr.html">thread_specific_ptr</a> types.
-        With these additions the <b>Boost.Threads</b> library can be considered
-        minimal but complete.</p>
-
-        <h4>The Next Phase</h4>
-
-        <p>The next phase will address more advanced synchronization concepts,
-        such as read/write mutexes and barriers.</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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/lock_concept.html

@@ -1,300 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, Lock Concept</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Lock Concepts</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Requirements">Concept Requirements</a><br>
-         <a href="#Lock">Lock Concept</a><br>
-         <a href="#ScopedLock">ScopedLock Concept</a><br>
-         <a href="#ScopedTryLock">ScopedTryLock Concept</a><br>
-         <a href="#ScopedTimedLock">ScopedTimedLock Concept</a><br>
-         <a href="#Models">Models</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The lock concepts provide exception safe means for locking and
-        unlocking a <a href="mutex_concept.html">mutex model</a>. In other
-        words they are an implementation of the <i>Scoped Locking</i> <a href=
-        "bibliography.html#Schmidt 00">[Schmidt 00]</a> pattern. The <a href=
-        "#ScopedLock">ScopedLock</a> concept, with <a href="#ScopedTryLock">
-        ScopedTryLock</a> and <a href="#ScopedTimedLock">ScopedTimedLock</a>
-        refinements, formalize the requirements.</p>
-
-        <p>Lock models are constructed with a reference to a <a href=
-        "mutex_concept.html">mutex model</a> and typically acquire ownership of
-        the <a href="mutex_concept.html">mutex model</a> by setting its state
-        to locked. They also ensure ownership is relinquished in the
-        destructor. Lock models also expose functions to query the lock status
-        and to manually lock and unlock the <a href="mutex_concept.html">mutex
-        model</a>.</p>
-
-        <p>Instances of lock models are meant to be short lived, expected to be
-        used at block scope only. The lock models are not <a href=
-        "definitions.html#Thread-safe">thread-safe</a>. Lock models must
-        maintain state to indicate whether or not they&#39;ve been locked and
-        this state is not protected by any synchronization concepts. For this
-        reason an instance of a lock model should never be shared between
-        multiple threads.</p>
-
-        <h2>Concept <a name="Requirements">Requirements</a></h2>
-
-        <p>[For documentation purposes, portions of the concept requirements
-        are repeated in the documentation for specific lock classes. Those
-        copies need to be kept in sync with the requirements here.]</p>
-
-        <h3><a name="Lock">Lock</a> Concept</h3>
-
-        <p>For a <a href="#ScopedLock">ScopedLock</a>, <a href=
-        "#ScopedTryLock">ScopedTryLock</a>, or <a href="#ScopedTimedLock">
-        ScopedTimedLock</a> type <code>L</code> and an object <code>lk</code>
-        and const object <code>clk</code> of that type, the following
-        expressions must be well-formed and have the indicated effects.</p>
-
-        <p>The Lock concept is used as a base for the <a href="#ScopedLock">
-        ScopedLock</a>, <a href="#ScopedTryLock">ScopedTryLock</a>, and <a
-        href="#ScopedTimedLock">ScopedTimedLock</a> refinements. The associated
-        mutex type is as specified for each of those refinements
-        respectively.</p>
-
-        <table summary="Lock expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>(&amp;lk)-&gt;~L();</code></td>
-
-                <td><code>if (locked()) unlock();</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>(&amp;clk)-&gt;operator const
-                void*()</code></td>
-
-                <td>Returns type void*, non-zero if if the associated mutex has
-                been locked by <code>clk</code>, otherwise 0.</td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>clk.locked()</code></td>
-
-                <td>Returns a <code>bool</code>, <code>(&amp;clk)-&gt;operator
-                const void*() != 0</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>lk.lock()</code></td>
-
-                <td>Throws lock_error if locked(). If the associated mutex is
-                already locked by some other thread, places the current thread
-                in the <a href="definitions.html#State">Blocked</a> state until
-                the associated mutex is unlocked, after which the current
-                thread is placed in the <a href="definitions.html#State">
-                Ready</a> state, eventually to be returned to the <a href=
-                "definitions.html#State">Running</a> state.<br>
-                 Postcondition: locked()</td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>lk.unlock()</code></td>
-
-                <td>If !locked(), throws lock_error, otherwise unlocks the
-                associated mutex.<br>
-                 Postcondition: !locked()</td>
-            </tr>
-        </table>
-
-        <h3><a name="ScopedLock">ScopedLock</a> Concept</h3>
-
-        <p>A ScopedLock must meet the <a href="#Lock">Lock</a> requirements.
-        For a ScopedLock type <code>L</code> and an object <code>lk</code> of
-        that type, and an object <code>m</code> of a type meeting the <a href=
-        "mutex_concept.html#Mutex">Mutex</a> requirements, and an object <code>
-        b</code> of type <code>bool</code>, the following expressions must be
-        well-formed and have the indicated effects.</p>
-
-        <table summary="ScopedLock expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then calls <code>lock()</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m,b);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then if <code>b</code>, calls <code>
-                lock()</code></td>
-            </tr>
-        </table>
-
-        <h3><a name="ScopedTryLock">ScopedTryLock</a> Concept</h3>
-
-        <p>A ScopedTryLock must meet the <a href="#Lock">Lock</a> requirements.
-        For a ScopedTryLock type <code>L</code> and an object <code>lk</code>
-        of that type, and an object <code>m</code> of a type meeting the <a
-        href="mutex_concept.html#TryMutex">TryMutex</a> requirements, and an
-        object <code>b</code> of type <code>bool</code>, the following
-        expressions must be well-formed and have the indicated effects.</p>
-
-        <table summary="ScopedTryLock expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then calls <code>try_lock()</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m,b);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then if <code>b</code>, calls <code>
-                lock()</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>lk.try_lock()</code></td>
-
-                <td>If locked(), throws <code>lock_error</code>. Makes a
-                non-blocking attempt to lock the associated mutex, returning
-                <code>true</code> if the lock attempt is successful, otherwise
-                <code>false</code>.</td>
-            </tr>
-        </table>
-
-        <h3><a name="ScopedTimedLock">ScopedTimedLock</a> Concept</h3>
-
-        <p>A ScopedTimedLock must meet the <a href="#Lock">Lock</a>
-        requirements. For a ScopedTimedLock type <code>L</code> and an object
-        <code>lk</code> of that type, and an object <code>m</code> of a type
-        meeting the <a href="mutex_concept.html#TimedMutex">TimedMutex</a>
-        requirements, and an object <code>b</code> of type <code>bool</code>,
-        and an object <code>t</code> of type <code><a href="xtime.html">
-        xtime</a></code>, the following expressions must be well-formed and
-        have the indicated effects.</p>
-
-        <table summary="ScopedTimedLock expressions" border="1" cellpadding=
-        "5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m,t);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then calls <code>
-                timed_lock(t)</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>L lk(m,b);</code></td>
-
-                <td>Constructs an object <code>lk</code>, and associates mutex
-                <code>m</code> with it, then if <code>b</code>, calls <code>
-                lock()</code></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code>lk.timed_lock(t)</code></td>
-
-                <td>If locked(), throws lock_error. Makes a blocking attempt to
-                lock the associated mutex, and returns <code>true</code> if
-                successful within the specified time <code>t</code>, otherwise
-                <code>false</code>.</td>
-            </tr>
-        </table>
-
-        <h2><a name="Models">Models</a></h2>
-
-        <p><b>Boost.Threads</b> currently supplies three classes which model
-        lock concepts.</p>
-
-        <p>These classes are normally accessed via typedefs of the same name
-        supplied by a <a href="mutex_concept.html">mutex model</a>.</p>
-
-        <table summary="Lock concept classes" border="1" cellpadding="5">
-            <tr>
-                <td><b>Concept</b></td>
-
-                <td><b>Refines</b></td>
-
-                <td><b>Classes Modeling the Concept</b></td>
-            </tr>
-
-            <tr>
-                <td><a href="#ScopedLock">ScopedLock</a></td>
-
-                <td>&nbsp;</td>
-
-                <td><a href="scoped_lock.html">scoped_lock</a></td>
-            </tr>
-
-            <tr>
-                <td><a href="#ScopedTryLock">ScopedTryLock</a></td>
-
-                <td><a href="#ScopedLock">ScopedLock</a></td>
-
-                <td><a href="scoped_try_lock.html">scoped_try_lock</a> </td>
-            </tr>
-
-            <tr>
-                <td><a href="#ScopedTimedLock">ScopedTimedLock</a></td>
-
-                <td><a href="#ScopedLock">ScopedLock</a></td>
-
-                <td><a href="scoped_timed_lock.html">scoped_timed_lock</a></td>
-            </tr>
-        </table>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/lock_error.html

@@ -1,110 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, lock_error</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">lock_error</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <tt>lock_error</tt> class defines an exception type thrown to
-        indicate a locking related error has been detected. Examples of such
-        errors include a lock operation which can be determined to result in a
-        deadlock, or unlock operations attempted by a thread that does not own
-        the lock.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost
-    
-    class lock_error : public std::runtime_error
-    {
-    public:
-       lock_error();
-    };
-}
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    lock_error();
-</pre>
-
-        <p>Constructs a <tt>lock_error</tt> object.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include &lt;iostream&gt;
-
-int main(int, char*[])
-{
-    boost::mutex mutex;
-    boost::mutex::scoped_lock scoped_lock(mutex);
-    try
-    {
-       boost::mutex::scoped_lock deadlock(mutex);
-       std::cout &lt;&lt; &quot;lock succeeded&quot; &lt;&lt; std::endl;
-    }
-    catch (boost::lock_error&amp; err)
-    {
-       std::cout &lt;&lt; err.what() &lt;&lt; &quot; - deadlock occurred.&quot; &lt;&lt; std::endl;
-    }
-    return 0;
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-thread lock error - deadlock occurred.
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/mutex-ref.xml

@@ -0,0 +1,308 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/mutex.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="mutex">
+		<purpose>
+			<para>The <classname>mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.Mutex">Mutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.Mutex">Mutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>try_mutex</classname> and <classname>timed_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics, see <classname>recursive_mutex</classname>,
+			<classname>recursive_try_mutex</classname>, and <classname>recursive_timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>mutex</classname> class supplies the following typedef,
+			which <link linkend="threads.concepts.lock-models">models</link>
+			the specified locking strategy:
+
+			<informaltable>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>			
+			</para>
+
+			<para>The <classname>mutex</classname> class uses an 
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in &Boost.Threads;, <classname>mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+	
+	<class name="try_mutex">
+		<purpose>
+			<para>The <classname>try_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryMutex">TryMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>try_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryMutex">TryMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>mutex</classname> and <classname>timed_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics, see <classname>recursive_mutex</classname>,
+			<classname>recursive_try_mutex</classname>, and <classname>recursive_timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>try_mutex</classname> class supplies the following typedefs,
+			which <link linkend="threads.concepts.lock-models">model</link>
+			the specified locking strategies:
+
+			<informaltable>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryLock">ScopedTryLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>
+			</para>
+
+			<para>The <classname>try_mutex</classname> class uses an 
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>try_mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in &Boost.Threads;, <classname>try_mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>try_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>try_mutex</classname> object.
+			</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+	
+	<class name="timed_mutex">
+		<purpose>
+			<para>The <classname>timed_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedMutex">TimedMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>timed_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedMutex">TimedMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>mutex</classname> and <classname>try_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics, see <classname>recursive_mutex</classname>,
+			<classname>recursive_try_mutex</classname>, and <classname>recursive_timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>timed_mutex</classname> class supplies the following typedefs,
+			which <link linkend="threads.concepts.lock-models">model</link>
+			the specified locking strategies:
+
+			<informaltable>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryLock">ScopedTryLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_timed_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTimedLock">ScopedTimedLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>
+			</para>
+
+			<para>The <classname>timed_mutex</classname> class uses an 
+			<link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>timed_mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all 
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in  &Boost.Threads;, <classname>timed_mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_timed_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>timed_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>timed_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+  </namespace>
+</header>

doc/mutex.html

@@ -1,359 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, mutex</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img alt="C++ Boost" src="../../../c++boost.gif" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">mutex<br>
-                     try_mutex<br>
-                     timed_mutex</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#mutex Synopsis">Class mutex Synopsis</a><br>
-         <a href="#mutex Members">Class mutex Members</a><br>
-         <a href="#try_mutex Synopsis">Class try_mutex Synopsis</a><br>
-         <a href="#try_mutex Members">Class try_mutex Members</a><br>
-         <a href="#timed_mutex Synopsis">Class timed_mutex Synopsis</a><br>
-         <a href="#timed_mutex Members">Class timed_mutex Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <tt><a href="#mutex Synopsis">mutex</a></tt>, <tt><a href=
-        "#try_mutex Synopsis">try_mutex</a></tt> and <tt><a href=
-        "#timed_mutex Synopsis">timed_mutex</a></tt> classes define full
-        featured models of the <a href="mutex_concept.html#Mutex">Mutex</a>, <a
-        href="mutex_concept.html#TryMutex">TryMutex</a>, and <a href=
-        "mutex_concept.html#TimedMutex">TimedMutex</a> concepts. These types
-        should be used to non-recursively synchronize access to shared
-        resources. For recursive locking mechanics, see <a href=
-        "recursive_mutex.html">recursive mutexes</a>.</p>
-
-        <p>Each class supplies one or more typedefs for lock types which model
-        matching lock concepts. For the best possible performance you should
-        use the mutex class that supports the minimum set of lock types that
-        you need.</p>
-
-        <table summary="lock types" border="1" cellpadding="5">
-            <tr>
-                <td><b>Mutex Class</b></td>
-
-                <td><b>Lock name</b></td>
-
-                <td><b>Implementation defined Lock Type</b></td>
-
-                <td><b>Lock Concept</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><a href="#mutex Synopsis"><code>
-                mutex</code></a></td>
-
-                <td valign="middle"><code>scoped_lock</code></td>
-
-                <td valign="middle"><code><a href="scoped_lock.html">
-                boost::</a></code><a href=
-                "scoped_lock.html"><code>detail::thread::scoped_lock&lt;mutex&gt;</code></a></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><tt><a href="#try_mutex Synopsis">
-                try_mutex</a></tt> </td>
-
-                <td valign="middle"><code>scoped_lock<br>
-                 scoped_try_lock</code></td>
-
-                <td valign="middle"><code><a href="scoped_lock.html">
-                boost::</a></code><a href=
-                "scoped_lock.html"><code>detail::thread::scoped_lock&lt;try_mutex&gt;<br>
-
-                </code></a> <code><a href="scoped_try_lock.html">
-                boost::detail::thread::scoped_try_lock&lt;try_mutex&gt;</a></code></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a><br>
-                 <a href="lock_concept.html#ScopedTryLock">
-                ScopedTryLock</a></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code><a href="#timed_mutex Synopsis">
-                timed_mutex</a></code> </td>
-
-                <td valign="middle"><code>scoped_lock<br>
-                 scoped_try_lock<br>
-                 scoped_timed_lock</code></td>
-
-                <td valign="middle"><code><a href="scoped_lock.html">
-                boost::</a></code><a href=
-                "scoped_lock.html"><code>detail::thread::scoped_lock&lt;timed_mutex&gt;</code></a><br>
-
-                 <code><a href="scoped_try_lock.html">boost::</a></code><a
-                href=
-                "scoped_try_lock.html"><code>detail::thread::scoped_try_lock&lt;timed_mutex&gt;</code></a><br>
-
-                 <code><a href="scoped_timed_lock.html">boost::</a></code><a
-                href=
-                "scoped_timed_lock.html"><code>detail::thread::scoped_timed_lock&lt;timed_mutex&gt;</code></a></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a><br>
-                 <a href="lock_concept.html#ScopedTryLock">
-                ScopedTryLock</a><br>
-                 <a href="lock_concept.html#ScopedTimedLock">
-                ScopedTimedLock</a></td>
-            </tr>
-        </table>
-
-        <p>The <tt>mutex</tt>, <tt>try_mutex</tt> and <tt>timed_mutex</tt>
-        classes use an <tt>Unspecified</tt> <a href=
-        "mutex_concept.html#LockingStrategies">locking strategy</a>, so
-        attempts to recursively lock them or attempts to unlock them by threads
-        that don&#39;t own a lock on them result in <b>undefined behavior</b>.
-        This strategy allows implementations to be as efficient as possible on
-        any given platform. It is, however, recommended that implementations
-        include debugging support to detect misuse when <tt>NDEBUG</tt> is not
-        defined.</p>
-
-        <p>Like all the <b>Boost.Threads</b> <a href="mutex_concept.html">mutex
-        models</a>, the <tt>mutex</tt>, <tt>try_mutex</tt> and <tt>
-        timed_mutex</tt> leave the <a href=
-        "mutex_concept.html#SchedulingPolicies">scheduling policy</a> as <tt>
-        Unspecified</tt>. Programmers should assume that threads waiting for a
-        lock on objects of these types acquire the lock in a random order, even
-        though the specific behavior for a given platform may be different.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a>
-</pre>
-
-        <h2>Class <a name="mutex Synopsis">mutex Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class mutex : private <a href=
-"../../utility/utility.htm">boost::noncopyable</a> // Exposition only.
-        // Class mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-        
-        mutex();
-        ~mutex();
-    };
-}
-</pre>
-
-        <h2>Class <a name="mutex Members">mutex Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash.</p>
-        <hr>
-
-        <h2>Class <a name="try_mutex Synopsis">try_mutex Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class try_mutex : private boost::noncopyable // Exposition only.
-        // Class try_mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_try_lock;
-        
-        try_mutex();
-        ~try_mutex();
-    };
-}
-</pre>
-
-        <h2>Class <a name="try_mutex Members">try_mutex Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    try_mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~try_mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash.</p>
-        <hr>
-
-        <h2>Class <a name="timed_mutex Synopsis">timed_mutex Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class timed_mutex : private boost::noncopyable // Exposition only.
-        // Class timed_mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_try_lock;
-        typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_timed_lock;
-        
-        timed_mutex();
-        ~timed_mutex();
-    };
-}
-</pre>
-
-        <h2>Class <a name="timed_mutex Members">timed_mutex Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    timed_mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~timed_mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include &lt;iostream&gt;
-
-boost::mutex io_mutex; // The iostreams are not guaranteed to be <a href=
-"definitions.html#Thread-safe">thread-safe</a>!
-
-class counter
-{
-public:
-    counter() : count(0) { }
-   
-    int increment() {
-        boost::mutex::scoped_lock scoped_lock(mutex);
-        return ++count;
-    }
-
-private:
-    boost::mutex mutex;
-    int count;
-};
-
-counter c;
-
-void change_count(void*)
-{
-    int i = c.increment();
-    boost::mutex::scoped_lock scoped_lock(io_mutex);
-    std::cout &lt;&lt; &quot;count == &quot; &lt;&lt; i &lt;&lt; std::endl;
-}
-
-int main(int, char*[])
-{
-    const int num_threads = 4;
-    boost::thread_group thrds;
-    for (int i=0; i &lt; num_threads; ++i)
-        thrds.create_thread(&amp;change_count, 0);
-      
-    thrds.join_all();
-   
-    return 0;
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-count == 1
-count == 2
-count == 3
-count == 4
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/mutex_concept.html

@@ -1,337 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, Mutex Concept</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Mutex Concepts</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#LockingStrategies">Locking Strategies</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Recursive">Recursive</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#CheckedStrategy">Checked</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#UncheckedStrategy">Unchecked</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp; <a href="#UnspecifiedStrategy">
-        Unspecified</a><br>
-         <a href="#SchedulingPolicies">Scheduling Policies</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#FIFO">FIFO</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Priority Driven">Priority
-        Driven</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp; <a href="#UndefinedScheduling">
-        Undefined</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp; <a href="#UnspecifiedScheduling">
-        Unspecified</a><br>
-         <a href="#Requirements">Concept Requirements</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Mutex">Mutex Concept</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TryMutex">TryMutex Concept</a><br>
-         &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TimedMutex">TimedMutex
-        Concept</a><br>
-         <a href="#Models">Models</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>A mutex (short for mutual-exclusion) concept serializes access to a
-        resource shared between multiple threads. The <a href="#Mutex">
-        Mutex</a> concept, with <a href="#TryMutex">TryMutex</a> and <a href=
-        "#TimedMutex">TimedMutex</a> refinements, formalize the requirements. A
-        model that implements Mutex and its refinements has two states: <b>
-        locked</b> and <b>unlocked</b>. Before using a shared resource, a
-        thread locks a Boost.Threads mutex model object, insuring <a href=
-        "definitions.html#Thread-safe">thread-safe</a> access to the shared
-        resource. When use of the shared resource is complete, the thread
-        unlocks the mutex model object, allowing another thread to acquire the
-        lock and use the shared resource.</p>
-
-        <p>Traditional C thread APIs, like Pthreads or the Windows thread APIs,
-        expose functions to lock and unlock a mutex model. This is dangerous
-        since it&#39;s easy to forget to unlock a locked mutex. When the flow
-        of control is complex, with multiple return points, the likelihood of
-        forgetting to unlock a mutex model would become even greater. When
-        exceptions are thrown, it becomes nearly impossible to ensure that the
-        mutex is unlocked properly when using these traditional API&#39;s. The
-        result is <a href="definitions.html#Deadlock">deadlock</a>.</p>
-
-        <p>Many C++ threading libraries use a pattern known as <i>Scoped
-        Locking</i> <a href="bibliography.html#Schmidt 00">[Schmidt 00]</a> to
-        free the programmer from the need to explicitly lock and unlock
-        mutexes. With this pattern, a <a href="lock_concept.html">lock
-        concept</a> is employed where the lock model&#39;s constructor locks
-        the associated mutex model and the destructor automatically does the
-        unlocking. The <b>Boost.Threads</b> library takes this pattern to the
-        extreme in that lock concepts are the only way to lock and unlock a
-        mutex model: lock and unlock functions are not exposed by any <b>
-        Boost.Threads</b> mutex models. This helps to ensure safe usage
-        patterns, especially when code throws exceptions.</p>
-
-        <h2><a name="LockingStrategies">Locking Strategies</a></h2>
-
-        <p>Every mutex model follows one of several locking strategies. These
-        strategies define the semantics for the locking operation when the
-        calling thread already owns a lock on the mutex model.</p>
-
-        <h3><a name="Recursive">Recursive</a></h3>
-
-        <p>With a recursive locking strategy when a thread attempts to acquire
-        a lock on the mutex model for which it already owns a lock, the
-        operation is successful. Note the distinction between a thread, which
-        may have multiple locks outstanding on a recursive mutex, and a lock
-        object, which even for a recursive mutex cannot have its lock()
-        function called multiple times without first calling unlock().</p>
-
-        <p>Internally a lock count is maintained and the owning thread must
-        unlock the mutex model the same number of times that it&#39;s locked it
-        before the mutex model&#39;s state returns to unlocked. Since mutex
-        models in <b>Boost.Threads</b> expose locking functionality only
-        through lock concepts, a thread will always unlock a mutex model the
-        same number of times that it locked it. This helps to eliminate a whole
-        set of errors typically found in traditional C style thread APIs.</p>
-
-        <p>Classes <a href="recursive_mutex.html">recursive_mutex</a>, <a href=
-        "recursive_mutex.html">recursive_try_mutex</a> and <a href=
-        "recursive_mutex.html">recursive_timed_mutex</a> use this locking
-        strategy.</p>
-
-        <h3><a name="CheckedStrategy">Checked</a></h3>
-
-        <p>With a checked locking strategy when a thread attempts to acquire a
-        lock on the mutex model for which the thread already owns a lock, the
-        operation will fail with some sort of error indication. Further,
-        attempts by a thread to unlock a mutex that was not locked by the
-        thread will also return some sort of error indication. In <b>
-        Boost.Threads</b>, an exception of type <a href="lock_error.html">
-        lock_error</a> would be thrown in these cases.</p>
-
-        <p><b>Boost.Threads</b> does not currently provide any mutex models
-        that use this strategy.</p>
-
-        <h3><a name="UncheckedStrategy">Unchecked</a></h3>
-
-        <p>With an unchecked locking strategy when a thread attempts to acquire
-        a lock on the mutex model for which the thread already owns a lock the
-        operation will <a href="definitions.html#Deadlock">deadlock</a>. In
-        general this locking strategy is less safe than a checked or recursive
-        strategy, but it&#39;s also a faster strategy and so is employed by
-        many libraries.</p>
-
-        <p><b>Boost.Threads</b> does not currently provide any mutex models
-        that use this strategy.</p>
-
-        <h3><a name="UnspecifiedStrategy">Unspecified</a></h3>
-
-        <p>With an unspecified locking strategy, when a thread attempts to
-        acquire a lock on a mutex model for which the thread already owns a
-        lock the operation results in <b>undefined behavior</b>. When a mutex
-        model has an unspecified locking strategy the programmer must assume
-        that the mutex model instead uses an unchecked strategy.</p>
-
-        <p>In general a mutex model with an unspecified locking strategy is
-        unsafe, and it requires programmer discipline to use the mutex model
-        properly. However, this strategy allows an implementation to be as fast
-        as possible with no restrictions on its implementation. This is
-        especially true for portable implementations that wrap the native
-        threading support of a platform. For this reason, the classes <a href=
-        "mutex.html">mutex</a>, <a href="mutex.html">try_mutex</a> and <a href=
-        "mutex.html">timed_mutex</a> use this locking strategy despite the lack
-        of safety.</p>
-
-        <h2><a name="SchedulingPolicies">Scheduling Policies</a></h2>
-
-        <p>Every mutex model follows one of several scheduling policies. These
-        policies define the semantics when the mutex model is unlocked and
-        there is more than one thread waiting to acquire a lock. In other
-        words, the policy defines which waiting thread shall acquire the
-        lock.</p>
-
-        <h3><a name="FIFO">FIFO</a></h3>
-
-        <p>With a FIFO scheduling policy, threads waiting for the lock will
-        acquire it in a first come first serve order (or First In First Out).
-        This can help prevent a high priority thread from starving lower
-        priority threads that are also waiting on the mutex lock.</p>
-
-        <h3><a name="Priority Driven">Priority Driven</a></h3>
-
-        <p>With a Priority Driven scheduling policy, the thread with the
-        highest priority acquires the lock. Note that this means that
-        low-priority threads may never acquire the lock if the mutex model has
-        high contention and there is always at least one high-priority thread
-        waiting. This is known as thread starvation. When multiple threads of
-        the same priority are waiting on the mutex lock one of the other
-        scheduling priorities will determine which thread shall acquire the
-        lock.</p>
-
-        <h3><a name="UndefinedScheduling">Undefined</a></h3>
-
-        <p>Threads acquire the lock in no particular order. Users should assume
-        that low-priority threads may wait indefinitely, and that threads of
-        the same priority acquire the lock in essentially random order.</p>
-
-        <h3><a name="UnspecifiedScheduling">Unspecified</a></h3>
-
-        <p>The mutex model does not specify which scheduling policy is used.
-        The programmer must assume that an undefined scheduling policy is used.
-        In order to ensure portability, all <b>Boost.Threads</b> mutex models
-        use an unspecified scheduling policy.</p>
-
-        <h2>Concept <a name="Requirements">Requirements</a></h2>
-
-        <h3><a name="Mutex">Mutex</a> Concept</h3>
-
-        <p>A Mutex object has two states: locked and unlocked. Mutex object
-        state can only be determined by an object meeting the <a href=
-        "lock_concept.html#ScopedLock">ScopedLock</a> requirements and
-        constructed for the Mutex object.</p>
-
-        <p>A Mutex is <a href="../../utility/utility.htm#Class noncopyable">
-        noncopyable</a>.</p>
-
-        <p>For a Mutex type M and an object m of that type, the following
-        expressions must be well-formed and have the indicated effects.</p>
-
-        <table summary="Mutex expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td><code>M m;</code></td>
-
-                <td>Constructs a mutex object m. Post-condition: m is
-                unlocked.</td>
-            </tr>
-
-            <tr>
-                <td><code>(&amp;m)-&gt;~M();</code></td>
-
-                <td>Precondition: m is unlocked. Destroys a mutex object
-                m.</td>
-            </tr>
-
-            <tr>
-                <td><code>M::scoped_lock</code></td>
-
-                <td>A type meeting the <a href="lock_concept.html#ScopedLock">
-                ScopedLock</a> requirements.</td>
-            </tr>
-        </table>
-
-        <h3><a name="TryMutex">TryMutex</a> Concept</h3>
-
-        <p>A TryMutex must meet the <a href="#Mutex">Mutex</a> requirements. In
-        addition, for a TryMutex type M and an object m of that type, the
-        following expressions must be well-formed and have the indicated
-        effects.</p>
-
-        <table summary="TryMutex expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td><code>M::scoped_try_lock</code></td>
-
-                <td>A type meeting the <a href=
-                "lock_concept.html#ScopedTryLock">ScopedTryLock</a>
-                requirements.</td>
-            </tr>
-        </table>
-
-        <h3><a name="TimedMutex">TimedMutex</a> Concept</h3>
-
-        <p>A TimedMutex must meet the <a href="#TryMutex">TryMutex</a>
-        requirements. In addition, for a TimedMutex type M and an object m of
-        that type, the following expressions must be well-formed and have the
-        indicated effects.</p>
-
-        <table summary="TimedMutex expressions" border="1" cellpadding="5">
-            <tr>
-                <td><b>Expression</b></td>
-
-                <td><b>Effects</b></td>
-            </tr>
-
-            <tr>
-                <td><code>M::scoped_timed_lock</code></td>
-
-                <td>A type meeting the <a href=
-                "lock_concept.html#ScopedTimedLock">ScopedTimedLock</a>
-                requirements.</td>
-            </tr>
-        </table>
-
-        <h2><a name="Models">Models</a></h2>
-
-        <p><b>Boost.Threads</b> currently supplies six classes which model
-        mutex concepts.</p>
-
-        <table summary="Mutex concept classes" border="1" cellpadding="5">
-            <tr>
-                <td><b>Concept</b></td>
-
-                <td><b>Refines</b></td>
-
-                <td><b>Classes Modeling the Concept</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><a href="#Mutex">Mutex</a></td>
-
-                <td valign="top">&nbsp;</td>
-
-                <td><a href="mutex.html">mutex</a><br>
-                 <a href="recursive_mutex.html">recursive_mutex</a></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><a href="#TryMutex">TryMutex</a></td>
-
-                <td valign="top"><a href="#Mutex">Mutex</a></td>
-
-                <td><a href="mutex.html">try_mutex<br>
-                </a> <a href="recursive_mutex.html">recursive_try_mutex</a>
-                </td>
-            </tr>
-
-            <tr>
-                <td valign="top"><a href="#TimedMutex">TimedMutex</a></td>
-
-                <td valign="top"><a href="#TryMutex">TryMutex</a></td>
-
-                <td><a href="mutex.html">timed_mutex<br>
-                </a> <a href="recursive_mutex.html">
-                recursive_timed_mutex</a></td>
-            </tr>
-        </table>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/once-ref.xml

@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/once.hpp"
+	last-revision="$Date$">
+	<macro name="BOOST_ONCE_INIT">
+		<purpose>The <functionname>call_once</functionname> function and
+		<code>once_flag</code> type (statically initialized to 
+		<macroname>BOOST_ONCE_INIT</macroname>) can be used to run a
+		routine exactly once. This can be used to initialize data in a
+		<link linkend="threads.glossary.thread-safe">thread-safe</link>
+		manner.</purpose>
+		
+		<description>The implementation-defined macro 
+		<macroname>BOOST_ONCE_INIT</macroname> is a constant value used to 
+		initialize <code>once_flag</code> instances to indicate that the 
+		logically associated routine has not been run yet. See 
+		<functionname>call_once</functionname> for more details.</description>
+	</macro>
+		
+	<namespace name="boost">
+		<typedef name="once_flag">
+			<purpose>The <functionname>call_once</functionname> function and
+			<code>once_flag</code> type (statically initialized to 
+			<macroname>BOOST_ONCE_INIT</macroname>) can be used to run a
+			routine exactly once. This can be used to initialize data in a
+			<link linkend="threads.glossary.thread-safe">thread-safe</link>
+			manner.</purpose>
+			
+			<description>The implementation-defined type <code>once_flag</code>
+			is used as a flag to insure a routine is called only once.
+			Instances of this type should be statically initialized to
+			<macroname>BOOST_ONCE_INIT</macroname>. See 
+			<functionname>call_once</functionname> for more details.
+			</description>
+
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+
+		<function name="call_once">
+			<purpose>The <functionname>call_once</functionname> function and
+			<code>once_flag</code> type (statically initialized to 
+			<macroname>BOOST_ONCE_INIT</macroname>) can be used to run a
+			routine exactly once. This can be used to initialize data in a
+			<link linkend="threads.glossary.thread-safe">thread-safe</link>
+			manner.</purpose>
+			
+			<description>
+			<para>Example usage is as follows:</para>
+			<para>
+<programlisting>//Example usage:
+boost::once_flag once = BOOST_ONCE_INIT;
+
+void init()
+{
+    //...
+}
+
+void thread_proc()
+{
+    boost::call_once(&amp;init, once);
+}</programlisting>
+			</para></description>
+			
+			<parameter name="func">
+				<paramtype>void (*func)()</paramtype>
+			</parameter>
+			
+			<parameter name="flag">
+				<paramtype>once_flag&amp;</paramtype>
+			</parameter>
+			
+			<requires>The function <code>func</code> shall not throw
+			exceptions.</requires>
+			
+			<effects>As if (in an atomic fashion): 
+			<code>if (flag == BOOST_ONCE_INIT) func();</code></effects>
+			
+			<postconditions><code>flag != BOOST_ONCE_INIT</code>
+			</postconditions>
+		</function>
+	</namespace>
+</header>

doc/overview.html

@@ -1,224 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=windows-1252">
-        <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-        <meta name="ProgId" content="FrontPage.Editor.Document">
-
-        <title>Boost.Threads Overview</title>
-    </head>
-
-    <body>
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Overview</h2>
-                </td>
-            </tr>
-        </table>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Dangers">Dangers</a><br>
-         <a href="#Library">C++ Standard Library usage</a><br>
-         <a href="#Common">Common requirements</a></p>
-
-        <h2><a name="Introduction">Introduction</a></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">Dangers</a></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>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>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">C++ Standard Library usage in multi-threaded
-        programs</a></h2>
-
-        <h3>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>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">Common</a> requirements for all Boost.Threads
-        components</h2>
-
-        <h3>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="NonCopyable">NonCopyable</a> 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>&copy; Copyright 2001 Beman Dawes</p>
-    </body>
-</html>
-

doc/overview.xml

@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.overview" last-revision="$Date$">
+  <title>Overview</title>
+  <section id="threads.introduction">
+    <title>Introduction</title>
+    <para>&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. The <link
+	linkend="threads.glossary">glossary</link> gives a more complete description
+	of the multithreading execution environment.</para>
+    <para>Multithreading provides several advantages:
+    <itemizedlist>
+      <listitem>
+        <para>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.</para>
+      </listitem>
+      <listitem>
+        <para>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 than single-threaded programs.</para>
+      </listitem>
+      <listitem>
+        <para>Some program designs may be easier to formulate using a
+        multithreaded approach. After all, the real world is
+        asynchronous!</para>
+      </listitem>
+    </itemizedlist></para>
+  </section>
+  <section>
+    <title>Dangers</title>
+    <section>
+    <title>General considerations</title>
+    <para>Beyond the errors which can occur in single-threaded programs,
+    multithreaded programs are subject to additional errors:
+    <itemizedlist>
+      <listitem>
+        <para><link linkend="threads.glossary.race-condition">Race
+	    conditions</link></para>
+      </listitem>
+      <listitem>
+        <para><link linkend="threads.glossary.deadlock">Deadlock</link>
+        (sometimes called "deadly embrace")</para>
+      </listitem>
+      <listitem>
+        <para><link linkend="threads.glossary.priority-failure">Priority
+        failures</link> (priority inversion, infinite overtaking, starvation,
+		etc.)</para>
+      </listitem>
+    </itemizedlist></para>
+    <para>Every multithreaded program must be designed carefully to avoid these
+	errors. 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.</para>
+    <para>The <link linkend="threads.design">&Boost.Threads; design</link>
+    attempts to minimize these errors, but they will still occur unless the
+    programmer proactively designs to avoid them.</para>
+	<note>Please also see <xref linkend="threads.implementation_notes"/>
+	for additional, implementation-specific considerations.</note>
+	</section>
+    <section>
+      <title>Testing and debugging considerations</title>
+      <para>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:
+      <itemizedlist>
+        <listitem>
+          <para>Failures are often not repeatable.</para>
+        </listitem>
+        <listitem>
+          <para>Probe effect causes debuggers to produce very different results
+          from non-debug uses.</para>
+        </listitem>
+        <listitem>
+          <para>Debuggers require special support to show thread state.</para>
+        </listitem>
+        <listitem>
+          <para>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.</para>
+        </listitem>
+        <listitem>
+          <para>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.</para>
+        </listitem>
+      </itemizedlist></para>
+    </section>
+    <section>
+      <title>Getting a head start</title>
+      <para>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.</para>
+      <para>Design patterns for reliable multithreaded programs, including the
+      important <emphasis>monitor</emphasis> pattern, are presented in 
+      <emphasis>Pattern-Oriented Software Architecture Volume 2 - Patterns for
+      Concurrent and Networked Objects</emphasis>
+	  &cite.SchmidtStalRohnertBuschmann;. Many important multithreading programming
+	  considerations (independent of threading library) are discussed in
+	  <emphasis>Programming with POSIX Threads</emphasis> &cite.Butenhof97;.</para>
+      <para>Doing some reading before attempting multithreaded designs will
+      give you a head start toward reliable multithreaded programs.</para>
+    </section>
+  </section>
+  <section>
+    <title>C++ Standard Library usage in multithreaded programs</title>
+    <section>
+      <title>Runtime libraries</title>
+      <para>
+      <emphasis role="bold">Warning:</emphasis> Multithreaded programs such as
+	  those using &Boost.Threads; must link to <link
+	  linkend="threads.glossary.thread-safe">thread-safe</link> versions of
+	  all runtime libraries used by the program, including the runtime library
+	  for the C++ Standard Library. Failure to do so will cause <link
+	  linkend="threads.glossary.race-condition">race conditions</link> to occur
+	  when multiple threads simultaneously execute runtime library functions for
+	  <code>new</code>, <code>delete</code>, or other language features which
+	  imply shared state.</para>
+    </section>
+    <section>
+      <title>Potentially non-thread-safe functions</title>
+      <para>Certain C++ Standard Library functions inherited from C are
+      particular problems because they hold internal state between
+      calls:
+      <itemizedlist>
+        <listitem>
+          <para><code>rand</code></para>
+        </listitem>
+        <listitem>
+          <para><code>strtok</code></para>
+        </listitem>
+        <listitem>
+          <para><code>asctime</code></para>
+        </listitem>
+        <listitem>
+          <para><code>ctime</code></para>
+        </listitem>
+        <listitem>
+          <para><code>gmtime</code></para>
+        </listitem>
+        <listitem>
+          <para><code>localtime</code></para>
+        </listitem>
+      </itemizedlist></para>
+      <para>It is possible to write thread-safe implementations of these by
+      using thread specific storage (see
+	  <classname>boost::thread_specific_ptr</classname>), and several C++ 
+	  compiler vendors do just that. The technique is well-know and is explained
+	  in &cite.Butenhof97;.</para>
+      <para>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.</para>
+      <para><emphasis role="bold">Recommendation:</emphasis> For the most
+	  portable, yet thread-safe code, use Boost replacements for the problem
+	  functions. See the <libraryname>Boost Random Number Library</libraryname>
+	  and <libraryname>Boost Tokenizer Library</libraryname>.</para>
+    </section>
+  </section>
+  <section>
+    <title>Common guarantees for all &Boost.Threads; components</title>
+    <section>
+      <title>Exceptions</title>
+      <para>&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.</para>
+      <para>In particular, &Boost.Threads;
+	  reports failure to allocate storage by throwing an exception of type
+	  <code>std::bad_alloc</code> or a class derived from
+	  <code>std::bad_alloc</code>, failure to obtain thread resources other than
+	  memory by throwing an exception of type
+	  <classname>boost::thread_resource_error</classname>, and certain lock
+	  related failures by throwing an exception of type
+	  <classname>boost::lock_error</classname>.</para>
+      <para><emphasis role="bold">Rationale:</emphasis> Follows the C++ Standard
+	  Library practice of allowing all functions except destructors or other
+	  specified functions to throw exceptions on errors.</para>
+    </section>
+    <section>
+      <title>NonCopyable requirement</title>
+      <para>&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 <classname>boost::noncopyable</classname>. Users
+	  should not depend on this derivation, however, as implementations are free
+	  to meet the NonCopyable requirement in other ways.</para>
+    </section>
+  </section>
+</section>

doc/rationale.html

@@ -1,481 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-
-        <title>Boost.Threads, rationale</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Rationale</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p>This page explains the rationale behind various design decisions in
-        the <b>Boost.Threads</b> library. Having the rationale documented here
-        should explain how we arrived at the current design as well as prevent
-        future rehashing of discussions and thought processes that have already
-        occurred. It can also give users a lot of insight into the design
-        process required for this library.</p>
-
-        <h2><a name="library">Rationale for the Creation of
-        Boost.Threads</a></h2>
-
-        <p>Processes often have a degree of &quot;potential parallelism&quot;
-        and it can often be more intuitive to design systems with this in mind.
-        Further, these parallel processes can result in more responsive
-        programs. The benefits for multi-threaded programming are quite well
-        known to most modern programmers, yet the C++ language doesn&#39;t
-        directly support this concept.</p>
-
-        <p>Many platforms support multi-threaded programming despite the fact
-        that the language doesn&#39;t support it. They do this through external
-        libraries, which are, unfortunately, platform specific. POSIX has tried
-        to address this problem through the standardization of a
-        &quot;pthread&quot; library. However, this is a standard only on POSIX
-        platforms, so its portability is limited.</p>
-
-        <p>Another problem with POSIX and other platform specific thread
-        libraries is that they are almost universally C based libraries. This
-        leaves several C++ specific issues unresolved, such as what happens
-        when an exception is thrown in a thread. Further, there are some C++
-        concepts, such as destructors, that can make usage much easier than
-        what&#39;s available in a C library.</p>
-
-        <p>What&#39;s truly needed is C++ language support for threads.
-        However, the C++ standards committee needs existing practice or a good
-        proposal as a starting point for adding this to the standard.</p>
-
-        <p>The Boost.Threads library was developed to provide a C++ developer
-        with a portable interface for writing multi-threaded programs on
-        numerous platforms. There&#39;s a hope that the library can be the
-        basis for a more detailed proposal for the C++ standards committee to
-        consider for inclusion in the next C++ standard.</p>
-
-        <h2><a name="primitives">Rationale for the Low Level Primitives
-        Supported in Boost.Threads</a></h2>
-
-        <p>The Boost.Threads library supplies a set of low level primitives for
-        writing multi-threaded programs, such as mutexes and condition variables.
-        In fact, the first release of Boost.Threads supports only these low level
-        primitives. However, computer science research has shown that use of these
-        primitives is difficult since there&#39;s no way to mathematically prove
-        that a usage pattern is correct, meaning it doesn&#39;t result in race
-        conditions or deadlocks. There are several algebras (such as CSP, CCS and
-        Join calculus) that have been developed to help write provably correct
-        parallel processes. In order to prove the correctness these processes must
-        be coded using higher level abstractions. So why does Boost.Threads support
-        the lower level concepts?</p>
-
-        <p>The reason is simple: the higher level concepts need to be
-        implemented using at least some of the lower level concepts. So having
-        portable lower level concepts makes it easier to develop the higher
-        level concepts and will allow researchers to experiment with various
-        techniques.</p>
-
-        <p>Beyond this theoretical application of higher level concepts,
-        however, the fact remains that many multi-threaded programs are written
-        using only the lower level concepts, so they are useful in and of
-        themselves, even if it&#39;s hard to prove that their usage is correct.
-        Since many users will be familiar with these lower level concepts but
-        be unfamiliar with any of the higher level concepts there&#39;s also an
-        argument for accessibility.</p>
-
-        <h2><a name="lock_objects">Rationale for the Lock Design</a></h2>
-
-        <p>Programmers who are used to multi-threaded programming issues will
-        quickly note that the Boost.Thread&#39;s design for mutex lock concepts
-        is not <a href="definitions.html#Thread-safe">thread-safe</a> (this is
-        clearly documented as well). At first this may seem like a serious
-        design flaw. Why have a multi-threading primitive that&#39;s not
-        thread-safe itself?</p>
-
-        <p>A lock object is not a synchronization primitive. A lock
-        object&#39;s sole responsibility is to ensure that a mutex is both
-        locked and unlocked in a manner that won&#39;t result in the common
-        error of locking a mutex and then forgetting to unlock it. This means
-        that instances of a lock object are only going to be created, at least
-        in theory, within block scope and won&#39;t be shared between threads.
-        Only the mutex objects will be created outside of block scope and/or
-        shared between threads. Though it&#39;s possible to create a lock
-        object outside of block scope and to share it between threads to do so
-        would not be a typical usage. Nor are there any cases when such usage
-        would be required.</p>
-
-        <p>Lock objects must maintain some state information. In order to allow
-        a program to determine if a try_lock or timed_lock was successful the
-        lock object must retain state indicating the success or failure of the
-        call made in its constructor. If a lock object were to have such state
-        and remain thread-safe it would need to synchronize access to the state
-        information which would result in roughly doubling the time of most
-        operations. Worse, since checking the state can occur only by a call
-        after construction we&#39;d have a race condition if the lock object
-        were shared between threads.</p>
-
-        <p>So, to avoid the overhead of synchronizing access to the state
-        information and to avoid the race condition the Boost.Threads library
-        simply does nothing to make lock objects thread-safe. Instead, sharing
-        a lock object between threads results in undefined behavior. Since the
-        only proper usage of lock objects is within block scope this isn&#39;t
-        a problem, and so long as the lock object is properly used there&#39;s
-        no danger of any multi-threading issues.</p>
-
-        <h2><a name="thread">Rationale for Non-copyable Thread Type</a></h2>
-
-        <p>Programmers who are used to C libraries for multi-threaded
-        programming are likely to wonder why Boost.Threads uses a non-copyable
-        design for <a href="thread.html">boost::thread</a>. After all, the C
-        thread types are copyable, and you often have a need for copying them
-        within user code. However, careful comparison of C designs to C++
-        designs shows a flaw in this logic.</p>
-
-        <p>All C types are copyable. It is, in fact, not possible to make a
-        non-copyable type in C. For this reason types that represent system
-        resources in C are often designed to behave very similarly to a pointer
-        to dynamic memory. There&#39;s an API for acquiring the resource and an
-        API for releasing the resources. For memory we have pointers as the
-        type and alloc/free for the acquisition and release APIs. For files we
-        have FILE* as the type and fopen/fclose for the acquisition and release
-        APIs. You can freely copy instances of the types but must manually
-        manage the lifetime of the actual resource through the acquisition and
-        release APIs.</p>
-
-        <p>C++ designs recognize that the acquisition and release APIs are
-        error prone and try to eliminate possible errors by acquiring the
-        resource in the constructor and releasing it in the destructor. The
-        best example of such a design is the std::iostream set of classes which
-        can represent the same resource as the FILE* type in C. A file is
-        opened in the std::fstream&#39;s constructor and closed in its
-        destructor. However, if an iostream were copyable it could lead to a
-        file being closed twice, an obvious error, so the std::iostream types
-        are noncopyable by design. This is the same design used by
-        boost::thread, which is a simple and easy to understand design
-        that&#39;s consistent with other C++ standard types.</p>
-
-        <p>During the design of boost::thread it was pointed out that it would
-        be possible to allow it to be a copyable type if some form of
-        &quot;reference management&quot; were used, such as ref-counting or
-        ref-lists, and many argued for a boost::thread_ref design instead. The
-        reasoning was that copying &quot;thread&quot; objects was a typical
-        need in the C libraries, and so presumably would be in the C++
-        libraries as well. It was also thought that implementations could
-        provide more efficient reference management then wrappers (such as
-        boost::shared_ptr) around a noncopyable thread concept. Analysis of
-        whether or not these arguments would hold true don&#39;t appear to bear
-        them out. To illustrate the analysis we&#39;ll first provide
-        pseudo-code illustrating the six typical usage patterns of a thread
-        object.</p>
-
-        <h3>1. Simple creation of a thread.</h3>
-<pre>
-void foo()
-{
-   create_thread(&amp;bar);
-}
-</pre>
-
-        <h3>2. Creation of a thread that&#39;s later joined.</h3>
-<pre>
-void foo()
-{
-   thread = create_thread(&amp;bar);
-   join(thread);
-}
-</pre>
-
-        <h3>3. Simple creation of several threads in a loop.</h3>
-<pre>
-void foo()
-{
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      create_thread(&amp;bar);
-}
-</pre>
-
-        <h3>4. Creation of several threads in a loop which are later
-        joined.</h3>
-<pre>
-void foo()
-{
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      threads[i] = create_thread(&amp;bar);
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      threads[i].join();
-}
-</pre>
-
-        <h3>5. Creation of a thread whose ownership is passed to another
-        object/method.</h3>
-<pre>
-void foo()
-{
-   thread = create_thread(&amp;bar);
-   manager.owns(thread);
-}
-</pre>
-
-        <h3>6. Creation of a thread whose ownership is shared between multiple
-        objects.</h3>
-<pre>
-void foo()
-{
-   thread = create_thread(&amp;bar);
-   manager1.add(thread);
-   manager2.add(thread);
-}
-</pre>
-
-        <p>Of these usage patterns there&#39;s only one that requires reference
-        management (number 6). Hopefully it&#39;s fairly obvious that this
-        usage pattern simply won&#39;t occur as often as the other usage
-        patterns. So there really isn&#39;t a &quot;typical need&quot; for a
-        thread concept, though there is some need.</p>
-
-        <p>Since the need isn&#39;t typical we must use different criteria for
-        deciding on either a thread_ref or thread design. Possible criteria
-        include ease of use and performance. So let&#39;s analyze both of these
-        carefully.</p>
-
-        <p>With ease of use we can look at existing experience. The standard
-        C++ objects that represent a system resource, such as std::iostream,
-        are noncopyable, so we know that C++ programmers must at least be
-        experienced with this design. Most C++ developers are also used to
-        smart pointers such as boost::shared_ptr, so we know they can at least
-        adapt to a thread_ref concept with little effort. So existing
-        experience isn&#39;t going to lead us to a choice.</p>
-
-        <p>The other thing we can look at is how difficult it is to use both
-        types for the six usage patterns above. If we find it overly difficult
-        to use a concept for any of the usage patterns there would be a good
-        argument for choosing the other design. So we&#39;ll code all six usage
-        patterns using both designs.</p>
-
-        <h3>1.</h3>
-<pre>
-void foo()
-{
-   thread thrd(&amp;bar);
-}
-
-void foo()
-{
-   thread_ref thrd = create_thread(&amp;bar);
-}
-</pre>
-
-        <h3>2.</h3>
-<pre>
-void foo()
-{
-   thread thrd(&amp;bar);
-   thrd.join();
-}
-
-void foo()
-{
-   thread_ref thrd = 
-   create_thread(&amp;bar);thrd-&gt;join();
-}
-</pre>
-
-        <h3>3.</h3>
-<pre>
-void foo()
-{
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      thread thrd(&amp;bar);
-}
-
-void foo()
-{
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      thread_ref thrd = create_thread(&amp;bar);
-}
-</pre>
-
-        <h3>4.</h3>
-<pre>
-void foo()
-{
-   std::auto_ptr&lt;thread&gt; threads[NUM_THREADS];
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      threads[i] = std::auto_ptr&lt;thread&gt;(new thread(&amp;bar));
-   for (int i= 0; i&lt;NUM_THREADS;
-      ++i)threads[i]-&gt;join();
-}
-
-void foo()
-{
-   thread_ref threads[NUM_THREADS];
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      threads[i] = create_thread(&amp;bar);
-   for (int i= 0; i&lt;NUM_THREADS;
-      ++i)threads[i]-&gt;join();    
-}
-</pre>
-
-        <h3>5.</h3>
-<pre>
-void foo()
-{
-   thread thrd* = new thread(&amp;bar);
-   manager.owns(thread);
-}
-
-void foo()
-{
-   thread_ref thrd = create_thread(&amp;bar);
-   manager.owns(thrd);
-}
-</pre>
-
-        <h3>6.</h3>
-<pre>
-void foo()
-{
-   boost::shared_ptr&lt;thread&gt; thrd(new thread(&amp;bar));
-   manager1.add(thrd);
-   manager2.add(thrd);
-}
-
-void foo()
-{
-   thread_ref thrd = create_thread(&amp;bar);
-   manager1.add(thrd);
-   manager2.add(thrd);
-}
-</pre>
-
-        <p>This shows the usage patterns being nearly identical in complexity
-        for both designs. The only actual added complexity occurs because of
-        the use of operator new in (4), (5) and (6) and the use of
-        std::auto_ptr and boost::shared_ptr in (4) and (6) respectively.
-        However, that&#39;s not really much added complexity, and C++
-        programmers are used to using these idioms any way. Some may dislike
-        the presence of operator new in user code, but this can be eliminated
-        by proper design of higher level concepts, such as the
-        boost::thread_group class that simplifies example (4) down to:</p>
-<pre>
-void foo()
-{
-   thread_group threads;
-   for (int i=0; i&lt;NUM_THREADS; ++i)
-      threads.create_thread(&amp;bar);
-   threads.join_all();
-}
-</pre>
-
-        <p>So ease of use is really a wash and not much help in picking a
-        design.</p>
-
-        <p>So what about performance? If you look at the above code examples we
-        can analyze the theoretical impact to performance that both designs
-        have. For (1) we can see that platforms that don&#39;t have a
-        ref-counted native thread type (POSIX, for instance) will be impacted
-        by a thread_ref design. Even if the native thread type is ref-counted
-        there may be an impact if more state information has to be maintained
-        for concepts foreign to the native API, such as clean up stacks for
-        Win32 implementations. For (2) the performance impact will be identical
-        to (1). The same for (3). For (4) things get a little more interesting
-        and we find that theoretically at least the thread_ref may perform
-        faster since the thread design requires dynamic memory
-        allocation/deallocation. However, in practice there may be dynamic
-        allocation for the thread_ref design as well, it will just be hidden
-        from the user. As long as the implementation has to do dynamic
-        allocations the thread_ref loses again because of the reference
-        management. For (5) we see the same impact as we do for (4). For (6) we
-        still have a possible impact to the thread design because of dynamic
-        allocation but thread_ref no longer suffers because of it&#39;s
-        reference management, and in fact, theoretically at least, the
-        thread_ref may do a better job of managing the references. All of this
-        indicates that thread wins for (1), (2) and (3), with (4) and (5) the
-        winner depends on the implementation and the platform but the thread
-        design probably has a better chance, and with (6) it will again depend
-        on the implementation and platform but this time we favor thread_ref
-        slightly. Given all of this it&#39;s a narrow margin, but the thread
-        design prevails.</p>
-
-        <p>Given this analysis, and the fact that noncopyable objects for
-        system resources are the normal designs that C++ programmers are used
-        to dealing with, the Boost.Threads library has gone with a noncopyable
-        design.</p>
-
-        <h2>Rationale for not providing <i><a name="Events">Event</a>
-        Variables</i></h2>
-
-        <p><i>Event variables</i> are simply far too error-prone. <a href=
-        "condition.html">Condition variables</a> are a much safer
-        alternative.</p>
-
-        <p>[Note that Graphical User Interface <i>events</i> are a different
-        concept, and are not what is being discussed here.]</p>
-
-        <p>Event variables were one of the first synchronization primitives.
-        They are still used today, for example, in the native Windows
-        multithreading API.</p>
-
-        <p>Yet both respected computer science researchers and experienced
-        multithreading practitioners believe event variables are so inherently
-        error-prone that they should never be used, and thus should not be part
-        of a multithreading library.</p>
-
-        <p>Per Brinch Hansen <a href="bibliography.html#Brinch-Hansen-73">
-        [Brinch Hansen 73]</a> analyzed event variables in some detail,
-        pointing out [emphasis his] that &quot;<i>event operations force the
-        programmer to be aware of the relative speeds of the sending and
-        receiving processes</i>&quot;. His summary:</p>
-
-        <blockquote>
-            <p>We must therefore conclude that event variables of the previous
-            type are impractical for system design. <i>The effect of an
-            interaction between two processes must be independent of the speed
-            at which it is carried out.</i></p>
-        </blockquote>
-
-        <p>Experienced programmers using the Windows platform today report that
-        event variables are a continuing source of errors, even after previous
-        bad experiences caused them to be very careful in their use of event
-        variables. Overt problems can be avoided, for example, by teaming the
-        event variable with a mutex, but that may just convert a <a href=
-        "definitions.html#Race condition">race condition</a> into another
-        problem, such as excessive resource use. One of the most distressing
-        aspects of the experience reports is the claim that many defects are
-        latent. That is, the programs appear to work correctly, but contain
-        hidden timing dependencies which will cause them to fail when
-        environmental factors or usage patterns change, altering relative
-        thread timings.</p>
-
-        <p>The decision to exclude event variables from Boost.Threads has been
-        surprising to some Windows programmers. They have written programs
-        which work using event variables, and wonder what the problem is. It
-        seems similar to the &quot;goto considered harmful&quot; controversy of
-        30 years ago. It isn&#39;t that events, like gotos, can&#39;t be made
-        to work, but rather that virtually all programs using alternatives will
-        be easier to write, debug, read, maintain, and be less likely to
-        contain latent defects.</p>
-
-        <p>[Rationale provided by Beman Dawes]</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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/rationale.xml

@@ -0,0 +1,434 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.rationale" last-revision="$Date$">
+  <title>Rationale</title>
+  <para>This page explains the rationale behind various design decisions in the
+  &Boost.Threads; library. Having the rationale documented here should explain
+  how we arrived at the current design as well as prevent future rehashing of
+  discussions and thought processes that have already occurred. It can also give
+  users a lot of insight into the design process required for this
+  library.</para>
+  <section id="threads.rationale.Boost.Threads">
+    <title>Rationale for the Creation of &Boost.Threads;</title>
+    <para>Processes often have a degree of "potential parallelism" and it can
+	often be more intuitive to design systems with this in mind. Further, these
+	parallel processes can result in more responsive programs. The benefits for
+	multithreaded programming are quite well known to most modern programmers,
+	yet the C++ language doesn't directly support this concept.</para>
+    <para>Many platforms support multithreaded programming despite the fact that
+	the language doesn't support it. They do this through external libraries,
+	which are, unfortunately, platform specific. POSIX has tried to address this
+	problem through the standardization of a "pthread" library. However, this is
+	a standard only on POSIX platforms, so its portability is limited.</para>
+    <para>Another problem with POSIX and other platform specific thread
+	libraries is that they are almost universally C based libraries. This leaves
+	several C++ specific issues unresolved, such as what happens when an
+	exception is thrown in a thread. Further, there are some C++ concepts, such
+	as destructors, that can make usage much easier than what's available in a C
+	library.</para>
+    <para>What's truly needed is C++ language support for threads. However, the
+	C++ standards committee needs existing practice or a good proposal as a
+	starting point for adding this to the standard.</para>
+    <para>The &Boost.Threads; library was developed to provide a C++ developer
+	with a portable interface for writing multithreaded programs on numerous
+	platforms. There's a hope that the library can be the basis for a more
+	detailed proposal for the C++ standards committee to consider for inclusion
+	in the next C++ standard.</para>
+  </section>
+  <section id="threads.rationale.primitives">
+    <title>Rationale for the Low Level Primitives Supported in &Boost.Threads;</title>
+    <para>The &Boost.Threads; library supplies a set of low level primitives for
+	writing multithreaded programs, such as mutexes and condition variables. In
+	fact, the first release of &Boost.Threads; supports only these low level
+	primitives. However, computer science research has shown that use of these
+	primitives is difficult since it's difficult to mathematically prove that a
+	usage pattern is correct, meaning it doesn't result in race conditions or
+	deadlocks. There are several algebras (such as CSP, CCS and Join calculus)
+	that have been developed to help write provably correct parallel
+	processes. In order to prove the correctness these processes must be coded
+	using higher level abstractions. So why does &Boost.Threads; support the
+	lower level concepts?</para>
+    <para>The reason is simple: the higher level concepts need to be implemented
+	using at least some of the lower level concepts. So having portable lower
+	level concepts makes it easier to develop the higher level concepts and will
+	allow researchers to experiment with various techniques.</para>
+    <para>Beyond this theoretical application of higher level concepts, however,
+	the fact remains that many multithreaded programs are written using only the
+	lower level concepts, so they are useful in and of themselves, even if it's
+	hard to prove that their usage is correct. Since many users will be familiar
+	with these lower level concepts but unfamiliar with any of the higher
+	level concepts, supporting the lower level concepts provides
+	greater accessibility.</para>
+  </section>
+  <section id="threads.rationale.locks">
+    <title>Rationale for the Lock Design</title>
+    <para>Programmers who are used to multithreaded programming issues will
+	quickly note that the &Boost.Threads; design for mutex lock concepts is not
+	<link linkend="threads.glossary.thread-safe">thread-safe</link> (this is
+	clearly documented as well). At first this may seem like a serious design
+	flaw. Why have a multithreading primitive that's not thread-safe
+	itself?</para>
+    <para>A lock object is not a synchronization primitive. A lock object's sole
+	responsibility is to ensure that a mutex is both locked and unlocked in a
+	manner that won't result in the common error of locking a mutex and then
+	forgetting to unlock it. This means that instances of a lock object are only
+	going to be created, at least in theory, within block scope and won't be
+	shared between threads. Only the mutex objects will be created outside of
+	block scope and/or shared between threads. Though it's possible to create a
+	lock object outside of block scope and to share it between threads, to do so
+	would not be a typical usage (in fact, to do so would likely be an
+	error). Nor are there any cases when such usage would be required.</para>
+    <para>Lock objects must maintain some state information. In order to allow a
+	program to determine if a try_lock or timed_lock was successful the lock
+	object must retain state indicating the success or failure of the call made
+	in its constructor. If a lock object were to have such state and remain
+	thread-safe it would need to synchronize access to the state information
+	which would result in roughly doubling the time of most operations. Worse,
+	since checking the state can occur only by a call after construction, we'd
+	have a race condition if the lock object were shared between threads.</para>
+    <para>So, to avoid the overhead of synchronizing access to the state
+	information and to avoid the race condition, the &Boost.Threads; library
+	simply does nothing to make lock objects thread-safe. Instead, sharing a
+	lock object between threads results in undefined behavior. Since the only
+	proper usage of lock objects is within block scope this isn't a problem, and
+	so long as the lock object is properly used there's no danger of any
+	multithreading issues.</para>
+  </section>
+  <section id="threads.rationale.non-copyable">
+    <title>Rationale for NonCopyable Thread Type</title>
+    <para>Programmers who are used to C libraries for multithreaded programming
+	are likely to wonder why &Boost.Threads; uses a noncopyable design for
+	<classname>boost::thread</classname>. After all, the C thread types are
+	copyable, and you often have a need for copying them within user
+	code. However, careful comparison of C designs to C++ designs shows a flaw
+	in this logic.</para>
+    <para>All C types are copyable. It is, in fact, not possible to make a
+	noncopyable type in C. For this reason types that represent system resources
+	in C are often designed to behave very similarly to a pointer to dynamic
+	memory. There's an API for acquiring the resource and an API for releasing
+	the resource. For memory we have pointers as the type and alloc/free for
+	the acquisition and release APIs. For files we have FILE* as the type and
+	fopen/fclose for the acquisition and release APIs. You can freely copy
+	instances of the types but must manually manage the lifetime of the actual
+	resource through the acquisition and release APIs.</para>
+    <para>C++ designs recognize that the acquisition and release APIs are error
+	prone and try to eliminate possible errors by acquiring the resource in the
+	constructor and releasing it in the destructor. The best example of such a
+	design is the std::iostream set of classes which can represent the same
+	resource as the FILE* type in C. A file is opened in the std::fstream's
+	constructor and closed in its destructor. However, if an iostream were
+	copyable it could lead to a file being closed twice, an obvious error, so
+	the std::iostream types are noncopyable by design. This is the same design
+	used by boost::thread, which is a simple and easy to understand design
+	that's consistent with other C++ standard types.</para>
+    <para>During the design of boost::thread it was pointed out that it would be
+	possible to allow it to be a copyable type if some form of "reference
+	management" were used, such as ref-counting or ref-lists, and many argued
+	for a boost::thread_ref design instead. The reasoning was that copying
+	"thread" objects was a typical need in the C libraries, and so presumably
+	would be in the C++ libraries as well. It was also thought that
+	implementations could provide more efficient reference management than
+	wrappers (such as boost::shared_ptr) around a noncopyable thread
+	concept. Analysis of whether or not these arguments would hold true doesn't
+	appear to bear them out. To illustrate the analysis we'll first provide
+	pseudo-code illustrating the six typical usage patterns of a thread
+	object.</para>
+	<section id="threads.rationale.non-copyable.simple">
+	  <title>1. Use case: Simple creation of a thread.</title>
+      <programlisting>
+      void foo()
+      {
+         create_thread(&amp;bar);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale.non-copyable.joined">
+	  <title>2. Use case: Creation of a thread that's later joined.</title>
+      <programlisting>
+      void foo()
+      {
+         thread = create_thread(&amp;bar);
+         join(thread);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale.non-copyable.loop">
+	  <title>3. Use case: Simple creation of several threads in a loop.</title>
+      <programlisting>
+      void foo()
+      {
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            create_thread(&amp;bar);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale.non-copyable.loop-join">
+	  <title>4. Use case: Creation of several threads in a loop which are later joined.</title>
+      <programlisting>
+      void foo()
+      {
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            threads[i] = create_thread(&amp;bar);
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            threads[i].join();
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale.non-copyable.pass">
+	  <title>5. Use case: Creation of a thread whose ownership is passed to another object/method.</title>
+      <programlisting>
+      void foo()
+      {
+         thread = create_thread(&amp;bar);
+         manager.owns(thread);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale.non-copyable.shared">
+	  <title>6. Use case: Creation of a thread whose ownership is shared between multiple
+	  objects.</title>
+	  <programlisting>
+      void foo()
+      {
+         thread = create_thread(&amp;bar);
+         manager1.add(thread);
+         manager2.add(thread);
+      }
+      </programlisting>
+	</section>
+    <para>Of these usage patterns there's only one that requires reference
+	management (number 6). Hopefully it's fairly obvious that this usage pattern
+	simply won't occur as often as the other usage patterns. So there really
+	isn't a "typical need" for a thread concept, though there is some
+	need.</para>
+    <para>Since the need isn't typical we must use different criteria for
+	deciding on either a thread_ref or thread design. Possible criteria include
+	ease of use and performance. So let's analyze both of these
+	carefully.</para>
+    <para>With ease of use we can look at existing experience. The standard C++
+	objects that represent a system resource, such as std::iostream, are
+	noncopyable, so we know that C++ programmers must at least be experienced
+	with this design. Most C++ developers are also used to smart pointers such
+	as boost::shared_ptr, so we know they can at least adapt to a thread_ref
+	concept with little effort. So existing experience isn't going to lead us to
+	a choice.</para>
+    <para>The other thing we can look at is how difficult it is to use both
+	types for the six usage patterns above. If we find it overly difficult to
+	use a concept for any of the usage patterns there would be a good argument
+	for choosing the other design. So we'll code all six usage patterns using
+	both designs.</para>
+	<section id="threads.rationale_comparison.non-copyable.simple">
+	  <title>1. Comparison: simple creation of a thread.</title>
+	  <programlisting>
+      void foo()
+      {
+         thread thrd(&amp;bar);
+      }
+      void foo()
+      {
+         thread_ref thrd = create_thread(&amp;bar);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale_comparison.non-copyable.joined">
+	  <title>2. Comparison: creation of a thread that's later joined.</title>
+	  <programlisting>
+      void foo()
+      {
+         thread thrd(&amp;bar);
+         thrd.join();
+      }
+      void foo()
+      {
+         thread_ref thrd =
+         create_thread(&amp;bar);thrd-&gt;join();
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale_comparison.non-copyable.loop">
+	  <title>3. Comparison: simple creation of several threads in a loop.</title>
+      <programlisting>
+      void foo()
+      {
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            thread thrd(&amp;bar);
+      }
+      void foo()
+      {
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            thread_ref thrd = create_thread(&amp;bar);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale_comparison.non-copyable.loop-join">
+	  <title>4. Comparison: creation of several threads in a loop which are later joined.</title>
+      <programlisting>
+      void foo()
+      {
+         std::auto_ptr&lt;thread&gt; threads[NUM_THREADS];
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            threads[i] = std::auto_ptr&lt;thread&gt;(new thread(&amp;bar));
+         for (int i= 0; i&lt;NUM_THREADS;
+             ++i)threads[i]-&gt;join();
+      }
+      void foo()
+      {
+         thread_ref threads[NUM_THREADS];
+         for (int i=0; i&lt;NUM_THREADS; ++i)
+            threads[i] = create_thread(&amp;bar);
+         for (int i= 0; i&lt;NUM_THREADS;
+            ++i)threads[i]-&gt;join();
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale_comparison.non-copyable.pass">
+	  <title>5. Comparison: creation of a thread whose ownership is passed to another object/method.</title>
+      <programlisting>
+      void foo()
+      {
+         thread thrd* = new thread(&amp;bar);
+         manager.owns(thread);
+      }
+      void foo()
+      {
+         thread_ref thrd = create_thread(&amp;bar);
+         manager.owns(thrd);
+      }
+      </programlisting>
+	</section>
+	<section id="threads.rationale_comparison.non-copyable.shared">
+	  <title>6. Comparison: creation of a thread whose ownership is shared 
+	  between multiple objects.</title>
+      <programlisting>
+      void foo()
+      {
+         boost::shared_ptr&lt;thread&gt; thrd(new thread(&amp;bar));
+         manager1.add(thrd);
+         manager2.add(thrd);
+      }
+      void foo()
+      {
+         thread_ref thrd = create_thread(&amp;bar);
+         manager1.add(thrd);
+         manager2.add(thrd);
+      }
+      </programlisting>
+	</section>
+    <para>This shows the usage patterns being nearly identical in complexity for
+	both designs. The only actual added complexity occurs because of the use of
+	operator new in 
+	<link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link>,
+	<link linkend="threads.rationale_comparison.non-copyable.pass">(5)</link>, and
+	<link linkend="threads.rationale_comparison.non-copyable.shared">(6)</link>;
+	and the use of std::auto_ptr and boost::shared_ptr in 
+	<link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link> and 
+	<link linkend="threads.rationale_comparison.non-copyable.shared">(6)</link>
+	respectively. However, that's not really
+	much added complexity, and C++ programmers are used to using these idioms
+	anyway. Some may dislike the presence of operator new in user code, but
+	this can be eliminated by proper design of higher level concepts, such as
+	the boost::thread_group class that simplifies example 
+	<link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link>
+	down to:</para>
+    <programlisting>
+    void foo()
+    {
+       thread_group threads;
+       for (int i=0; i&lt;NUM_THREADS; ++i)
+          threads.create_thread(&amp;bar);
+       threads.join_all();
+    }
+    </programlisting>
+    <para>So ease of use is really a wash and not much help in picking a
+	design.</para>
+    <para>So what about performance? Looking at the above code examples, 
+    we can analyze the theoretical impact to performance that both designs
+	have. For <link linkend="threads.rationale_comparison.non-copyable.simple">(1)</link>
+	we can see that platforms that don't have a ref-counted native
+	thread type (POSIX, for instance) will be impacted by a thread_ref
+	design. Even if the native thread type is ref-counted there may be an impact
+	if more state information has to be maintained for concepts foreign to the
+	native API, such as clean up stacks for Win32 implementations. 
+	For <link linkend="threads.rationale_comparison.non-copyable.joined">(2)</link>
+	and <link linkend="threads.rationale_comparison.non-copyable.loop">(3)</link>
+	the performance impact will be identical to
+	<link linkend="threads.rationale_comparison.non-copyable.simple">(1)</link>.
+	For <link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link>
+	things get a little more interesting and we find that theoretically at least
+	the thread_ref may perform faster since the thread design requires dynamic
+	memory allocation/deallocation. However, in practice there may be dynamic
+	allocation for the thread_ref design as well, it will just be hidden from
+	the user. As long as the implementation has to do dynamic allocations the
+	thread_ref loses again because of the reference management. For 
+	<link linkend="threads.rationale_comparison.non-copyable.pass">(5)</link> we see
+	the same impact as we do for 
+	<link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link>.
+	For <link linkend="threads.rationale_comparison.non-copyable.shared">(6)</link>
+	we still have a possible impact to
+	the thread design because of dynamic allocation but thread_ref no longer
+	suffers because of its reference management, and in fact, theoretically at
+	least, the thread_ref may do a better job of managing the references. All of
+	this indicates that thread wins for 
+	<link linkend="threads.rationale_comparison.non-copyable.simple">(1)</link>, 
+	<link linkend="threads.rationale_comparison.non-copyable.joined">(2)</link> and 
+	<link linkend="threads.rationale_comparison.non-copyable.loop">(3)</link>; with 
+	<link linkend="threads.rationale_comparison.non-copyable.loop-join">(4)</link>
+	and <link linkend="threads.rationale_comparison.non-copyable.pass">(5)</link> the
+	winner depending on the implementation and the platform but with the thread design
+	probably having a better chance; and with 
+	<link linkend="threads.rationale_comparison.non-copyable.shared">(6)</link> 
+	it will again depend on the
+	implementation and platform but this time we favor thread_ref
+	slightly. Given all of this it's a narrow margin, but the thread design
+	prevails.</para>
+	<para>Given this analysis, and the fact that noncopyable objects for system
+	resources are the normal designs that C++ programmers are used to dealing
+	with, the &Boost.Threads; library has gone with a noncopyable design.</para>
+  </section>
+  <section id="threads.rationale.events">
+    <title>Rationale for not providing <emphasis>Event Variables</emphasis></title>
+    <para><emphasis>Event variables</emphasis> are simply far too
+	error-prone. <classname>boost::condition</classname> variables are a much safer
+	alternative. [Note that Graphical User Interface <emphasis>events</emphasis> are 
+	a different concept, and are not what is being discussed here.]</para>
+    <para>Event variables were one of the first synchronization primitives. They
+	are still used today, for example, in the native Windows multithreading
+	API. Yet both respected computer science researchers and experienced
+	multithreading practitioners believe event variables are so inherently
+	error-prone that they should never be used, and thus should not be part of a
+	multithreading library.</para>
+    <para>Per Brinch Hansen &cite.Hansen73; analyzed event variables in some
+	detail, pointing out [emphasis his] that "<emphasis>event operations force
+	the programmer to be aware of the relative speeds of the sending and
+	receiving processes</emphasis>". His summary:</para>
+    <blockquote>
+      <para>We must therefore conclude that event variables of the previous type
+	  are impractical for system design. <emphasis>The effect of an interaction
+	  between two processes must be independent of the speed at which it is
+	  carried out.</emphasis></para>
+    </blockquote>
+    <para>Experienced programmers using the Windows platform today report that
+	event variables are a continuing source of errors, even after previous bad
+	experiences caused them to be very careful in their use of event
+	variables. Overt problems can be avoided, for example, by teaming the event
+	variable with a mutex, but that may just convert a <link
+	linkend="threads.glossary.race-condition">race condition</link> into another
+	problem, such as excessive resource use. One of the most distressing aspects
+	of the experience reports is the claim that many defects are latent. That
+	is, the programs appear to work correctly, but contain hidden timing
+	dependencies which will cause them to fail when environmental factors or
+	usage patterns change, altering relative thread timings.</para>
+    <para>The decision to exclude event variables from &Boost.Threads; has been
+	surprising to some Windows programmers. They have written programs which
+	work using event variables, and wonder what the problem is. It seems similar
+	to the "goto considered harmful" controversy of 30 years ago. It isn't that
+	events, like gotos, can't be made to work, but rather that virtually all
+	programs using alternatives will be easier to write, debug, read, maintain,
+	and will be less likely to contain latent defects.</para>
+    <para>[Rationale provided by Beman Dawes]</para>
+  </section>
+</section>

doc/read_write_mutex-ref.xml

@@ -0,0 +1,362 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/read_write_mutex.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+	<namespace name="read_write_scheduling_policy">
+		<enum name="read_write_scheduling_policy">
+			<enumvalue name="writer_priority" />
+			<enumvalue name="reader_priority" />
+			<enumvalue name="alternating_many_reads" />
+			<enumvalue name="alternating_single_read" />
+
+			<purpose>
+				<para>Specifies the 
+				<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+				to use when a set of threads try to obtain different types of
+				locks simultaneously.</para>
+			</purpose>
+
+			<description>
+				<para>The only clock type supported by &Boost.Threads; is 
+				<code>TIME_UTC</code>. The epoch for <code>TIME_UTC</code>
+				is 1970-01-01 00:00:00.</para>
+			</description>
+		</enum>
+	</namespace>
+	
+    <class name="read_write_mutex">
+		<purpose>
+			<para>The <classname>read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.ReadWriteMutex">ReadWriteMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.ReadWriteMutex">ReadWriteMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>try_read_write_mutex</classname> and <classname>timed_read_write_mutex</classname>.</para>
+			
+			<para>The <classname>read_write_mutex</classname> class supplies the following typedef,
+			which <link linkend="threads.concepts.read-write-lock-models">models</link>
+			the specified locking strategy:
+
+			<informaltable>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedReadWriteLock">ScopedReadWriteLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>			
+			</para>
+
+			<para>The <classname>read_write_mutex</classname> class uses an 
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>read_write_mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.read-write-mutex-models">read/write mutex models</link>
+			in &Boost.Threads;, <classname>read_write_mutex</classname> has two types of
+			<link linkend="threads.concepts.read-write-scheduling-policies">scheduling policies</link>, an 
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			between threads trying to obtain different types of locks and an
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link>
+			between threads trying to obtain the same type of lock.
+			The <classname>read_write_mutex</classname> class allows the
+			programmer to choose what
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			will be used; however, like all read/write mutex models, 
+			<classname>read_write_mutex</classname> leaves the 
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link> as 
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>.			
+			</para>
+			
+			<note>Self-deadlock is virtually guaranteed if a thread tries to
+			lock the same <classname>read_write_mutex</classname> multiple times
+			unless all locks are read-locks (but see below)</note>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<parameter name="count">
+				<paramtype>boost::read_write_scheduling_policy</paramtype>
+			</parameter>
+
+			<effects>Constructs a <classname>read_write_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>read_write_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+
+    <class name="try_read_write_mutex">
+		<purpose>
+			<para>The <classname>try_read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryReadWriteMutex">TryReadWriteMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>try_read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryReadWriteMutex">TryReadWriteMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>read_write_mutex</classname> and <classname>timed_read_write_mutex</classname>.</para>
+			
+			<para>The <classname>try_read_write_mutex</classname> class supplies the following typedefs,
+			which <link linkend="threads.concepts.read-write-lock-models">model</link>
+			the specified locking strategy:
+
+			<informaltable>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedReadWriteLock">ScopedReadWriteLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryReadWriteLock">ScopedTryReadWriteLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>			
+			</para>
+
+			<para>The <classname>try_read_write_mutex</classname> class uses an 
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>try_read_write_mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.read-write-mutex-models">read/write mutex models</link>
+			in &Boost.Threads;, <classname>try_read_write_mutex</classname> has two types of
+			<link linkend="threads.concepts.read-write-scheduling-policies">scheduling policies</link>, an 
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			between threads trying to obtain different types of locks and an
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link>
+			between threads trying to obtain the same type of lock.
+			The <classname>try_read_write_mutex</classname> class allows the
+			programmer to choose what
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			will be used; however, like all read/write mutex models, 
+			<classname>try_read_write_mutex</classname> leaves the 
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link> as 
+			<link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>.			
+			</para>
+			
+			<note>Self-deadlock is virtually guaranteed if a thread tries to
+			lock the same <classname>try_read_write_mutex</classname> multiple times
+			unless all locks are read-locks (but see below)</note>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<parameter name="count">
+				<paramtype>boost::read_write_scheduling_policy</paramtype>
+			</parameter>
+
+			<effects>Constructs a <classname>try_read_write_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>try_read_write_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+
+    <class name="timed_read_write_mutex">
+		<purpose>
+			<para>The <classname>timed_read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedReadWriteMutex">TimedReadWriteMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>timed_read_write_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedReadWriteMutex">TimedReadWriteMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>read_write_mutex</classname> and <classname>try_read_write_mutex</classname>.</para>
+			
+			<para>The <classname>timed_read_write_mutex</classname> class supplies the following typedefs,
+			which <link linkend="threads.concepts.read-write-lock-models">model</link>
+			the specified locking strategy:
+
+			<informaltable>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedReadWriteLock">ScopedReadWriteLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryReadWriteLock">ScopedTryReadWriteLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_timed_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTimedReadWriteLock">ScopedTimedReadWriteLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</informaltable>			
+			</para>
+
+			<para>The <classname>timed_read_write_mutex</classname> class uses an 
+			<link linkend="threads.concepts.read-write-locking-strategies.unspecified">Unspecified</link>
+			locking strategy, so attempts to recursively lock a <classname>timed_read_write_mutex</classname>
+			object or attempts to unlock one by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.
+			This strategy allows implementations to be as efficient as possible
+			on any given platform. It is, however, recommended that
+			implementations include debugging support to detect misuse when
+			<code>NDEBUG</code> is not defined.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.read-write-mutex-models">read/write mutex models</link>
+			in &Boost.Threads;, <classname>timed_read_write_mutex</classname> has two types of
+			<link linkend="threads.concepts.read-write-scheduling-policies">scheduling policies</link>, an 
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			between threads trying to obtain different types of locks and an
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link>
+			between threads trying to obtain the same type of lock.
+			The <classname>timed_read_write_mutex</classname> class allows the
+			programmer to choose what
+			<link linkend="threads.concepts.read-write-scheduling-policies.inter-class">inter-class sheduling policy</link>
+			will be used; however, like all read/write mutex models, 
+			<classname>timed_read_write_mutex</classname> leaves the 
+			<link linkend="threads.concepts.read-write-scheduling-policies.intra-class">intra-class sheduling policy</link> as 
+			<link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>.			
+			</para>
+			
+			<note>Self-deadlock is virtually guaranteed if a thread tries to
+			lock the same <classname>timed_read_write_mutex</classname> multiple times
+			unless all locks are read-locks (but see below)</note>
+		</description>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_timed_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<parameter name="count">
+				<paramtype>boost::read_write_scheduling_policy</paramtype>
+			</parameter>
+
+			<effects>Constructs a <classname>timed_read_write_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>timed_read_write_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+  </namespace>
+</header>

doc/recursive_mutex-ref.xml

@@ -0,0 +1,302 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/recursive_mutex.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="recursive_mutex">
+		<purpose>
+			<para>The <classname>recursive_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.Mutex">Mutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>recursive_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.Mutex">Mutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>recursive_try_mutex</classname> and <classname>recursive_timed_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics, see <classname>mutex</classname>,
+			<classname>try_mutex</classname>, and <classname>timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>recursive_mutex</classname> class supplies the following typedef,
+			which models the specified locking strategy:
+
+			<table>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</table>			
+			</para>
+
+			<para>The <classname>recursive_mutex</classname> class uses a
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking strategy, so attempts to recursively lock a 
+			<classname>recursive_mutex</classname> object
+			succeed and an internal "lock count" is maintained. 
+			Attempts to unlock a <classname>recursive_mutex</classname> object
+			by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in &Boost.Threads;, <classname>recursive_mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>recursive_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>recursive_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+	
+	<class name="recursive_try_mutex">
+		<purpose>
+			<para>The <classname>recursive_try_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryMutex">TryMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>recursive_try_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TryMutex">TryMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>recursive_mutex</classname> and <classname>recursive_timed_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics, see <classname>mutex</classname>,
+			<classname>try_mutex</classname>, and <classname>timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>recursive_try_mutex</classname> class supplies the following typedefs,
+			which model the specified locking strategies:
+
+			<table>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryLock">ScopedTryLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</table>
+			</para>
+
+			<para>The <classname>recursive_try_mutex</classname> class uses a
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking strategy, so attempts to recursively lock a 
+			<classname>recursive_try_mutex</classname> object
+			succeed and an internal "lock count" is maintained. 
+			Attempts to unlock a <classname>recursive_mutex</classname> object
+			by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.</para>
+			
+			<para>Like all
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in &Boost.Threads;, <classname>recursive_try_mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>recursive_try_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>recursive_try_mutex</classname> object.
+			</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+	
+	<class name="recursive_timed_mutex">
+		<purpose>
+			<para>The <classname>recursive_timed_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedMutex">TimedMutex</link> concept.</para>
+		</purpose>
+		
+		<description>
+			<para>The <classname>recursive_timed_mutex</classname> class is a model of the 
+			<link linkend="threads.concepts.TimedMutex">TimedMutex</link> concept. 
+			It should be used to synchronize access to shared resources using
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking mechanics.</para>
+
+			<para>For classes that model related mutex concepts, see 
+			<classname>recursive_mutex</classname> and <classname>recursive_try_mutex</classname>.</para>
+
+			<para>For <link linkend="threads.concepts.unspecified-locking-strategy">Unspecified</link>
+			locking mechanics, see <classname>mutex</classname>,
+			<classname>try_mutex</classname>, and <classname>timed_mutex</classname>.
+			</para>
+			
+			<para>The <classname>recursive_timed_mutex</classname> class supplies the following typedefs,
+			which model the specified locking strategies:
+
+			<table>
+				<title>Supported Lock Types</title>
+				<tgroup cols="2" align="left">
+					<thead>
+						<row>
+							<entry>Lock Name</entry>
+							<entry>Lock Concept</entry>
+						</row>
+					</thead>
+					<tbody>
+						<row>
+							<entry>scoped_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedLock">ScopedLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_try_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTryLock">ScopedTryLock</link></entry>
+						</row>
+						<row>
+							<entry>scoped_timed_lock</entry>
+							<entry><link linkend="threads.concepts.ScopedTimedLock">ScopedTimedLock</link></entry>
+						</row>
+					</tbody>
+				</tgroup>
+			</table>
+			</para>
+
+			<para>The <classname>recursive_timed_mutex</classname> class uses a
+			<link linkend="threads.concepts.recursive-locking-strategy">Recursive</link>
+			locking strategy, so attempts to recursively lock a 
+			<classname>recursive_timed_mutex</classname> object
+			succeed and an internal "lock count" is maintained. 
+			Attempts to unlock a <classname>recursive_mutex</classname> object
+			by threads that don't own a lock on it result in
+			<emphasis role="bold">undefined behavior</emphasis>.</para>
+			
+			<para>Like all 
+			<link linkend="threads.concepts.mutex-models">mutex models</link>
+			in  &Boost.Threads;, <classname>recursive_timed_mutex</classname> leaves the 
+			<link linkend="threads.concepts.sheduling-policies">scheduling policy</link>
+			as <link linkend="threads.concepts.unspecified-scheduling-policy">Unspecified</link>. 
+			Programmers should make no assumptions about the order in which
+			waiting threads acquire a lock.</para>
+		</description>
+		
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+		
+		<typedef name="scoped_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_try_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<typedef name="scoped_timed_lock">
+			<type><emphasis>implementation-defined</emphasis></type>
+		</typedef>
+		
+		<constructor>
+			<effects>Constructs a <classname>recursive_timed_mutex</classname> object.
+			</effects>
+			
+			<postconditions><code>*this</code> is in an unlocked state.
+			</postconditions>
+		</constructor>
+
+		<destructor>
+			<effects>Destroys a <classname>recursive_timed_mutex</classname> object.</effects>
+			
+			<requires><code>*this</code> is in an unlocked state.</requires>
+			
+			<notes><emphasis role="bold">Danger:</emphasis> Destruction of a
+			locked mutex is a serious programming error resulting in undefined
+			behavior such as a program crash.</notes>
+		</destructor>
+	</class>
+  </namespace>
+</header>

doc/recursive_mutex.html

@@ -1,368 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, recursive_mutex</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0" width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">recursive_mutex<br>
-                     recursive_try_mutex<br>
-                     recursive_timed_mutex</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-        <a href="#Header">Header</a><br>
-        <a href="#recursive_mutex Synopsis">Class recursive_mutex
-        Synopsis</a><br>
-        <a href="#recursive_mutex Members">Class recursive_mutex
-        Members</a><br>
-        <a href="#recursive_try_mutex Synopsis">Class recursive_try_mutex
-        Synopsis</a><br>
-        <a href="#recursive_try_mutex Members">Class recursive_try_mutex
-        Members</a><br>
-        <a href="#recursive_timed_mutex Synopsis">Class recursive_timed_mutex
-        Synopsis</a><br>
-        <a href="#recursive_timed_mutex Members">Class recursive_timed_mutex
-        Members</a><br>
-        <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>recursive_mutex</code>, <code>recursive_try_mutex</code>
-        and <code>recursive_timed_mutex</code> classes define full featured
-        models of the <a href="mutex_concept.html#Mutex">Mutex</a>, <a href=
-        "mutex_concept.html#TryMutex">TryMutex</a> and <a href=
-        "mutex_concept.html#TimedMutex">TimedMutex</a> concepts with recursive
-        locking semantics. These types should be used to synchronize access to
-        shared resources when recursive locking by a single thread is likely to
-        occur. A good example for this is when a class supplies &quot;internal
-        synchronization&quot; to ensure <a href="definitions.html#Thread-safe">
-        thread-safety</a> and a function of the class may have to call other
-        functions of the class which also attempt to lock the mutex. For
-        recursive locking mechanics, see <a href="mutex.html">mutexes</a>.</p>
-
-        <p>Each class supplies one or more typedefs for lock types which model
-        matching lock concepts. For the best possible performance you should
-        use the mutex class that supports the minimum set of lock types that
-        you need.</p>
-
-        <table summary="lock types" border="1" cellpadding="5">
-            <tr>
-                <td><b>Mutex Class</b></td>
-
-                <td><b>Lock name</b></td>
-
-                <td><b>Implementation defined Lock Type</b></td>
-
-                <td><b>Lock Concept</b></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><a href="#recursive_mutex Synopsis"><code>
-                recursive_mutex</code></a></td>
-
-                <td valign="middle"><code>scoped_lock</code></td>
-
-                <td valign="middle"><a href="scoped_lock.html"><code>
-                detail::thread::scoped_lock&lt;recursive_mutex&gt;</code></a></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code><a href="#recursive_try_mutex Synopsis">
-                recursive_try_mutex</a></code></td>
-
-                <td valign="middle"><code>scoped_lock<br>
-                 scoped_try_lock</code></td>
-
-                <td valign="middle"><a href="scoped_lock.html"><code>
-                detail::thread::scoped_lock&lt;recursive_try_mutex&gt;<br>
-                </code></a> <code><a href="scoped_try_lock.html">
-                detail::thread::scoped_try_lock&lt;recursive_try_mutex&gt;</a></code></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a><br>
-                 <a href="lock_concept.html#ScopedTryLock">
-                ScopedTryLock</a></td>
-            </tr>
-
-            <tr>
-                <td valign="top"><code><a href=
-                "#recursive_timed_mutex Synopsis">
-                recursive_timed_mutex</a></code> </td>
-
-                <td valign="middle"><code>scoped_lock<br>
-                 scoped_try_lock<br>
-                 scoped_timed_lock</code></td>
-
-                <td valign="middle"><a href="scoped_lock.html"><code>
-                detail::thread::scoped_lock&lt;recursive_timed_mutex&gt;</code></a><br>
-
-                 <a href="scoped_try_lock.html"><code>
-                detail::thread::scoped_try_lock&lt;recursive_timed_mutex&gt;</code></a><br>
-
-                 <a href="scoped_timed_lock.html"><code>
-                detail::thread::scoped_timed_lock&lt;recursive_timed_mutex&gt;</code></a></td>
-
-                <td valign="middle"><a href="lock_concept.html#ScopedLock">
-                ScopedLock</a><br>
-                 <a href="lock_concept.html#ScopedTryLock">
-                ScopedTryLock</a><br>
-                 <a href="lock_concept.html#ScopedTimedLock">
-                ScopedTimedLock</a></td>
-            </tr>
-        </table>
-
-        <p>The <code>recursive_mutex</code>, <code>recursive_try_mutex</code>
-        and <code>recursive_timed_mutex</code> employ a <code>Recursive</code>
-        <a href="mutex_concept.html#LockingStrategies">locking strategy</a>, so
-        attempts to recursively lock them succeed and an internal &quot;lock
-        count&quot; is maintained. Attempts to unlock them by a thread that
-        does not own a lock on them will result in a <a href="lock_error.html">
-        lock_error</a> exception being thrown.</p>
-
-        <p>The <code>recursive_mutex</code>, <code>recursive_try_mutex</code>
-        and <code>recursive_timed_mutex</code> leave the <a href=
-        "mutex_concept.html#SchedulingPolicies">scheduling policy</a> as <code>
-        Unspecified</code>. Programmers should assume that threads waiting for
-        a lock on objects of these types acquire the lock in a random order,
-        even though the specific behavior for a given platform may be
-        different.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/recursive_mutex.hpp">&lt;boost/thread/recursive_mutex.hpp&gt;</a>
-</pre>
-
-        <h2>Class <a name="recursive_mutex Synopsis">recursive_mutex
-        Synopsis</a></h2>
-        <hr>
-<pre>
-namespace boost
-{
-   class recursive_mutex : private <a href=
-"../../utility/utility.htm">boost::noncopyable</a> // Exposition only.
-        // Class recursive_mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-   {
-   public:
-      typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-      
-      recursive_mutex();
-      ~recursive_mutex();
-   };
-}
-</pre>
-
-        <h2>Class <a name="recursive_mutex Members">recursive_mutex
-        Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    recursive_mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~recursive_mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash..</p>
-        <hr>
-
-        <h2>Class <a name="recursive_try_mutex Synopsis">recursive_try_mutex
-        Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class recursive_try_mutex : private boost::noncopyable // Exposition only.
-        // Class recursive_try_mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-       typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-       typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_try_lock;
-      
-       recursive_try_mutex();
-       ~recursive_try_mutex();
-    };
-}
-</pre>
-
-        <h2>Class <a name="recursive_try_mutex Members">recursive_try_mutex
-        Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    recursive_try_mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~recursive_try_mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash..</p>
-        <hr>
-
-        <h2>Class <a name="recursive_timed_mutex Synopsis">
-        recursive_timed_mutex Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class recursive_timed_mutex : private boost::noncopyable // Exposition only.
-        // Class recursive_timed_mutex meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-       typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_lock;
-       typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_try_lock;
-       typedef <i>[implementation defined; see <a href=
-"#Introduction">Introduction</a>]</i> scoped_timed_lock;
-      
-       recursive_timed_mutex();
-       ~recursive_timed_mutex();
-    };
-}
-</pre>
-
-        <h2>Class <a name="recursive_timed_mutex Members">recursive_timed_mutex
-        Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    recursive_timed_mutex();
-</pre>
-
-        <p><b>Postconditions:</b> <code>*this</code> is in the unlocked
-        state.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~recursive_timed_mutex();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is in the unlocked state.</p>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>.</p>
-
-        <p><b>Dangers:</b> Destruction of a locked mutex is a serious
-        programming error resulting in undefined behavior such as a program
-        crash..</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include <a href=
-"../../../boost/thread/recursive_mutex.hpp">&lt;boost/thread/recursive_mutex.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include &lt;iostream&gt;
-
-class counter
-{
-public:
-    counter() : count(0) { }
-
-    int add(int val) {
-        boost::recursive_mutex::scoped_lock scoped_lock(mutex);
-        count += val;
-        return count;
-    }   
-    int increment() {
-        boost::recursive_mutex::scoped_lock scoped_lock(mutex);
-        return add(1);
-    }
-
-private:
-    boost::recursive_mutex mutex;
-    int count;
-};
-
-counter c;
-
-void change_count(void*)
-{
-    std::cout &lt;&lt; &quot;count == &quot; &lt;&lt; c.increment() &lt;&lt; std::endl;
-}
-
-int main(int, char*[])
-{
-    const int num_threads=4;
-
-    boost::thread_group threads;   
-    for (int i=0; i &lt; num_threads; ++i)
-        threads.create_thread(&amp;change_count, 0);
-      
-    threads.join_all();
-   
-    return 0;
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-count == 1
-count == 2
-count == 3
-count == 4
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/reference.xml

@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<library-reference id="threads.reference"
+  last-revision="$Date$"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+  <xi:include href="barrier-ref.xml"/>
+  <xi:include href="condition-ref.xml"/>
+  <xi:include href="exceptions-ref.xml"/>
+  <xi:include href="mutex-ref.xml"/>
+  <xi:include href="once-ref.xml"/>
+  <xi:include href="recursive_mutex-ref.xml"/>
+  <xi:include href="read_write_mutex-ref.xml"/>
+  <xi:include href="thread-ref.xml"/>
+  <xi:include href="tss-ref.xml"/>
+  <xi:include href="xtime-ref.xml"/>
+</library-reference>

doc/release_notes.xml

@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<section id="threads.release_notes" last-revision="$Date$">
+	<title>Release Notes</title>
+	<section id="threads.release_notes.boost_1_32_0">
+		<title>Boost 1.32.0</title>
+
+		<section id="threads.release_notes.boost_1_32_0.change_log.documentation">
+			<title>Documentation converted to BoostBook</title>
+
+			<para>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!</para>
+		</section>
+
+		<section id="threads.release_notes.boost_1_32_0.change_log.static_link">
+			<title>Static-link build option added</title>
+
+			<para>The option to link &Boost.Threads; as a static
+			library has been added back with some limitations.
+			This feature was originally removed because
+			<classname>boost::thread_specific_ptr</classname> required
+			that &Boost.Threads; be dynamically linked in order for its
+			cleanup functionality to work on Win32 platforms.
+			Several options are currently being explored to resolve
+			this issue. In the meantime, the ability to link 
+			&Boost.Threads; statically has been added back 
+			<emphasis>with <classname>boost::thread_specific_ptr</classname>
+			support removed</emphasis> from the statically linked version.
+			The decision to add it back was made because its lack is
+			one of the most frequent complaints about &Boost.Threads;
+			and because the other approaches that are being investigated 
+			to deal with <classname>boost::thread_specific_ptr</classname>
+			cleanup look fairly promising.
+			<note>&Boost.Threads; is still dynamically linked by default.
+			In order to force it to be statically linked, it is necessary to
+			#define BOOST_THREAD_USE_LIB before any of the &Boost.Threads;
+			header files are #included.</note>
+			<note>If the <classname>boost::thread_specific_ptr</classname> cleanup
+			issue cannot be resolved by some other means, it is highly
+			likely that the option to statically link &Boost.Threads;
+			will be removed again in a future version of Boost, at least
+			for Win32 platforms. This is because the 
+			<classname>boost::thread_specific_ptr</classname> functionality
+			will be increasingly used by &Boost.Threads; itself,
+			so that proper cleanup will become essential
+			in future versions of &Boost.Threads;.</note>
+			</para>
+		</section>
+		
+		<section id="threads.release_notes.boost_1_32_0.change_log.barrier">
+			<title>Barrier functionality added</title>
+
+			<para>A new class, <classname>boost::barrier</classname>, was added.</para>
+		</section>
+		
+		<section id="threads.release_notes.boost_1_32_0.change_log.read_write_mutex">
+			<title>Read/write mutex functionality added</title>
+
+			<para>New classes, 
+			<classname>boost::read_write_mutex</classname>,
+			<classname>boost::try_read_write_mutex</classname>, and
+			<classname>boost::timed_read_write_mutex</classname>
+			were added.</para>
+		</section>
+		
+		<section id="threads.release_notes.boost_1_32_0.change_log.thread_specific_ptr">
+			<title>Thread-specific pointer functionality changed</title>
+
+			<para>The <classname>boost::thread_specific_ptr</classname> 
+			constructor now takes an optional pointer to a cleanup function that
+			is called to release the thread-specific data that is being pointed
+			to by <classname>boost::thread_specific_ptr</classname> objects.</para>
+
+			<para>Fixed: the number of available thread-specific storage "slots"
+			is too small on some platforms.</para>
+
+			<para>Fixed: <functionname>thread_specific_ptr::reset()</functionname>
+			doesn't check error returned by <functionname>tss::set()</functionname>
+			(the <functionname>tss::set()</functionname> function now throws
+			if it fails instead of returning an error code).</para>
+
+			<para>Fixed: calling 
+			<functionname>boost::thread_specific_ptr::reset()</functionname> or 
+			<functionname>boost::thread_specific_ptr::release()</functionname>
+			causes double-delete: once when 
+			<functionname>boost::thread_specific_ptr::reset()</functionname> or
+			<functionname>boost::thread_specific_ptr::release()</functionname> 
+			is called and once when 
+			<functionname>boost::thread_specific_ptr::~thread_specific_ptr()</functionname>
+			is called.</para>
+		</section>
+
+		<section id="threads.release_notes.boost_1_32_0.change_log.mutex">
+			<title>Mutex implementation changed for Win32</title>
+
+			<para>On Win32, <classname>boost::mutex</classname>, 
+			<classname>boost::try_mutex</classname>, <classname>boost::recursive_mutex</classname>,
+			and <classname>boost::recursive_try_mutex</classname> now use a Win32 critical section 
+			whenever possible; otherwise they use a Win32 mutex. As before, 
+			<classname>boost::timed_mutex</classname> and 
+			<classname>boost::recursive_timed_mutex</classname> use a Win32 mutex.</para>
+		</section>
+	</section>
+</section>

doc/removed_atomic_t.html

@@ -1,134 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<meta name="keywords" content="threads, BTL, thread library, C++">
-<title>Boost.Threads, atomic_t</title>
-</head>
-
-<body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-
-<table border="0" cellpadding="7" cellspacing="0" width="100%">
-    <tr>
-        <td valign="top" width="300">
-			<h3><img src="../../../c++boost.gif" alt="C++ Boost" width="277" height="86"></h3>
-        </td>
-        <td valign="top">
-			<h1 align="center">Boost.Threads</h1>
-			<h2 align="center">atomic_t</h2>
-        </td>
-    </tr>
-</table>
-
-<hr>
-
-<h2>Header</h2>
-
-<p>The <tt>atomic_t</tt> class defines an "atomic integer" type.  This class should be used
-to perform thread safe operations on an integral type with out the overhead of locks. Only
-a limited set of integer operations are available with an <tt>atomic_t</tt> instance.</p>
-
-<pre>
-#include &lt;boost/thread/atomic.hpp&gt;
-</pre>
-
-<h2>Public Interface</h2>
-
-<pre>
-    class atomic_t
-    {
-    public:
-       typedef <b>implementation defined</b> value_type;
-
-       explicit atomic_t(value_type val=0);
-    };
-
-    atomic_t::value_type read(const atomic_t&amp; x);
-    atomic_t::value_type increment(atomic_t&amp; x);
-    atomic_t::value_type decrement(atomic_t&amp; x);
-    atomic_t::value_type swap(atomic_t&amp; x, atomic_t::value_type y);
-    atomic_t::value_type compare_swap(atomic_t&amp; x, atomic_t::value_type y, atomic_t::value_type z);
-</pre>
-
-<h3>Constructor</h3>
-
-<pre>
-    atomic_t(atomic_t::value_type val=0);
-</pre>
-
-<p>Constructs an <tt>atomic_t</tt> and sets its value to <tt>val</tt>.</p>
-
-<h3>read</h3>
-
-<pre>
-     atomic_t::value_type read(const atomic_t&amp; x);
-</pre>
-
-<p>Gets the current value of <tt>x</tt>.</p>
-
-<h3>increment</h3>
-
-<pre>
-    atomic_t::value_type increment(atomic_t&amp; x);
-</pre>
-
-<p>Increments <tt>x</tt> and returns a value <tt>&lt; 0</tt> if the result is less than 0,
-<tt>&gt; 0</tt> if the result is greater than 0 and <tt>== 0</tt> if the result is equal to
-0.</p>
-
-<h3>decrement</h3>
-
-<pre>
-    atomic_t::value_type decrement(atomic_t&amp; x);
-</pre>
-
-<p>Decrements <tt>x</tt> and returns a value <tt>&lt; 0</tt> if the result is less than 0,
-<tt>&gt; 0</tt> if the result is greater than 0 and <tt>== 0</tt> if the result is equal to
-0.</p>
-
-<h3>swap</h3>
-
-<pre>
-    atomic_t::value_type swap(atomic_t&amp; x, atomic_t::value_type y);
-</pre>
-
-<p>Assigns the value of <tt>y</tt> to <tt>x</tt> and returns the value of <tt>x</tt> prior
-to the swap.</p>
-
-<h3>compare_swap</h3>
-
-<pre>
-    atomic_t::value_type compare_swap(atomic_t&amp; x, atomic_t::value_type y, atomic_t::value_type z);
-</pre>
-
-<p>Compares the value of <tt>z</tt> to the value of <tt>x</tt> and if equal sets the value of
-<tt>x</tt> to the value of <tt>y</tt> and returns the value of <tt>x</tt> prior to the swap.</p>
-
-<h2>Example Usage</h2>
-
-<pre>
-#include &lt;boost/thread/atomic.hpp&gt;
-#include &lt;boost/test/test_tools.hpp&gt;
-
-int test_main(int, char*[])
-{
-    boost::atomic_t a;
-    BOOST_TEST_VERIFY(boost::read(a) == 0);
-    BOOST_TEST_VERIFY(boost::increment(a) &gt; 0);
-    BOOST_TEST_VERIFY(boost::decrement(a) == 0);
-    BOOST_TEST_VERIFY(boost::swap(a, 1) == 0);
-    BOOST_TEST_VERIFY(boost::swap(a, 2, 0) == 1);
-    BOOST_TEST_VERIFY(boost::read(a) == 1);
-}
-</pre>
-
-<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:williamkempf@hotmail.com">William E. Kempf</a>
-2001 all rights reserved.</i></p>
-
-</body>
-</html>

doc/scoped_lock.html

@@ -1,227 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, scoped_lock</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">scoped_lock</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>This class template defines a generic lock type which meets the <a
-        href="lock_concept.html#ScopedLock">ScopedLock</a> requirements. The <a
-        href="mutex.html">mutex</a>, <a href="mutex.html">try_mutex</a>, <a
-        href="mutex.html">timed_mutex</a>, <a href="recursive_mutex.html">
-        recursive_mutex</a>, <a href="recursive_mutex.html">
-        recursive_try_mutex</a> and <a href="recursive_mutex.html">
-        recursive_timed_mutex</a> classes all use this template to define their
-        <code>scoped_lock</code> types.</p>
-
-        <p>Like all the <b>Boost.Threads</b> <a href="lock_concept.html">lock
-        models</a>, <code>scoped_lock</code> objects are meant to be
-        short-lived. Objects of the class are not <a href=
-        "definitions.html#thread-safe">thread-safe</a>, and so should not be
-        shared between threads.</p>
-
-        <p>Class <code>scoped_lock</code> follows the &quot;resource
-        acquisition is initialization&quot; idiom <a href=
-        "bibliography.html#Stroustrup-00">[Stroustrup 00 14.4.1]</a> and is a
-        realization of the &quot;Scoped Locking Pattern&quot; <a href=
-        "bibliography.html#Schmidt-00">[Schmidt-00]</a>. Thus the usage is to
-        let the constructor do the locking, and then let the destructor do the
-        unlocking automatically at the end of the enclosing scope. The lock()
-        and unlock() members are usually not explicitly called, but are
-        provided to allow for complex overlapping locks of multiple
-        mutexes.</p>
-
-        <p>The type used to instantiate the class must meet the <a href=
-        "mutex_concept.html#Mutex">Mutex</a> requirements.</p>
-
-        <p>Although this class is an implementation detail, it is publicly
-        documented here because of its importance.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/detail/lock.hpp">&lt;boost/thread/detail/lock.hpp&gt;</a>
-    <i>This header is usually not included directly by programmers
-    because it is supplied by <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a> or
-    <a href=
-"../../../boost/thread/recursive_mutex.hpp">&lt;boost/thread/recursive_mutex.hpp&gt;</a></i>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost { namespace detail { namespace thread {
-    template &lt;typename Mutex&gt;
-    class scoped_lock : private <a href=
-"../../utility/utility.htm#Class noncopyable">boost::noncopyable</a> // Exposition only.
-        // Class scoped_lock meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef Mutex mutex_type;
-        
-        explicit scoped_lock(Mutex&amp; mx, bool initially_locked=true);
-        ~scoped_lock();
-        
-        void lock();
-        void unlock();
-        
-        operator const void*() const;
-        bool locked() const;
-    };
-} // namespace thread
-} // namespace detail
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    explicit scoped_lock(Mutex&amp; mx, bool initially_locked=true);
-</pre>
-
-        <p><b>Effects:</b> Associates mutex <code>mx</code> with <code>
-        *this</code>. If <code>initially_locked</code> is <code>true,</code>
-        calls <code>lock()</code>.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~scoped_lock();
-</pre>
-
-        <p><b>Effects:</b> If <code>locked()</code>, calls <code>
-        unlock()</code>. Destroys <code>*this</code>.</p>
-        <hr>
-
-        <h3>lock</h3>
-<pre>
-    void lock();
-</pre>
-
-        <p><b>Effects:</b> If the associated mutex is already locked by another
-        lock in the current thread, the effects depend on the locking strategy
-        of the associated mutex, as shown in the following table:</p>
-
-        <table summary="lock effects" border="1" cellpadding="5">
-            <tr>
-                <td><i><a href="mutex_concept.html#LockingStrategies">Locking
-                Strategy</a><br>
-                 of associated mutex</i></td>
-
-                <td><i>Effect if associated mutex is already locked by the
-                current thread</i></td>
-            </tr>
-
-            <tr>
-                <td>Recursive</td>
-
-                <td>As if an additional lock were added to the mutex.</td>
-            </tr>
-
-            <tr>
-                <td>Checked</td>
-
-                <td>Throws <a href="lock_error.html">lock_error</a>.</td>
-            </tr>
-
-            <tr>
-                <td>Unchecked</td>
-
-                <td>Undefined behavior [<a href="bibliography.html#ISO">ISO</a>
-                1.3.12] (but typically, <a href="definitions.html#Deadlock">
-                deadlock</a>.)</td>
-            </tr>
-        </table>
-
-        <p>If the associated mutex is already locked by some other thread,
-        places the current thread in the <a href="definitions.html#State">
-        Blocked</a> state until the associated mutex is unlocked, after which
-        the current thread is placed in the <a href="definitions.html#State">
-        Ready</a> state, eventually to be returned to the <a href=
-        "definitions.html#State">Running</a> state.</p>
-
-        <p><b>Postcondition:</b> locked()</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        locked()</code> or as indicated in <b>Effects</b>.</p>
-        <hr>
-
-        <h3>unlock</h3>
-<pre>
-    void unlock();
-</pre>
-
-        <p><b>Effects:</b> Unlocks the associated mutex.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        !locked()</code>.</p>
-        <hr>
-
-        <h3>const void* Conversion</h3>
-<pre>
-    operator const void*() const;
-</pre>
-
-        <p><b>Returns:</b> If the associated mutex is currently locked, a value
-        convertible to <code>true</code>, else a value convertible to <code>
-        false</code>.</p>
-
-        <p><b>Rationale:</b> A <code>const void*</code> conversion is
-        considered safer than a conversion to <code>bool</code>.</p>
-        <hr>
-
-        <h3>locked</h3>
-<pre>
-    bool locked() const;
-</pre>
-
-        <p><b>Returns:</b> <code>this-&gt;operator const void*() !=
-        0</code>.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-
-        <p>See the example given in the documentation for the <a href=
-        "mutex.html">mutex</a> class.</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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/scoped_timed_lock.html

@@ -1,267 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, scoped_timed_lock</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">scoped_timed_lock</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>This class template defines a generic lock type which meets the <a
-        href="lock_concept.html#ScopedTimedLock">ScopedTimedLock</a>
-        requirements. The <a href="mutex.html">timed_mutex</a> and <a href=
-        "recursive_mutex.html">recursive_timed_mutex</a> classes use this
-        template to define their <code>scoped_timed_lock</code> types.</p>
-
-        <p>Like all the <b>Boost.Threads</b> <a href="lock_concept.html">lock
-        models</a>, <code>scoped_timed_lock</code> objects are meant to be
-        short-lived. Objects of the class are not <a href=
-        "definitions.html#thread-safe">thread-safe</a>, and so should not be
-        shared between threads.</p>
-
-        <p>Class <code>scoped_timed_lock</code> follows the &quot;resource
-        acquisition is initialization&quot; idiom <a href=
-        "bibliography.html#Stroustrup-00">[Stroustrup 00 14.4.1]</a> and is a
-        realization of the &quot;Scoped Locking Pattern&quot; <a href=
-        "bibliography.html#Schmidt-00">[Schmidt-00]</a>. Thus the usage is to
-        let the constructor do the locking, and then let the destructor do the
-        unlocking automatically at the end of the enclosing scope. The lock()
-        and unlock() members are usually not explicitly called, but are
-        provided to allow for complex overlapping locks of multiple
-        mutexes.</p>
-
-        <p>The type used to instantiate the class must meet the <a href=
-        "mutex_concept.html#TimedMutex">TimedMutex</a> requirements.</p>
-
-        <p>Although this class is an implementation detail, it is publicly
-        documented here because of its importance.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/detail/lock.hpp">&lt;boost/thread/detail/lock.hpp&gt;</a>
-    <i>This header is usually not included directly by programmers
-    because it is supplied by <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a> or
-    <a href=
-"../../../boost/thread/recursive_mutex.hpp">&lt;boost/thread/recursive_mutex.hpp&gt;</a></i>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost { namespace detail { namespace thread {
-    template &lt;typename TimedMutex&gt;
-    class scoped_timed_lock : private <a href=
-"../../utility/utility.htm#Class noncopyable">boost::noncopyable</a> // Exposition only.
-        // Class scoped_timed_lock meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef TimedMutex mutex_type;
-
-        scoped_timed_lock(TimedMutex&amp; mx, const boost::xtime&amp; xt);
-        scoped_timed_lock(TimedMutex&amp; mx, bool initially_locked);
-        ~scoped_timed_lock();
-        
-        void lock();
-        bool timed_lock(const xtime&amp; xt);
-        void unlock();
-        
-        operator const void*() const;
-    };
-} // namespace thread
-} // namesapce detail
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    scoped_timed_lock(TimedMutex&amp; mx, const <a href=
-"xtime.html">xtime</a>&amp; xt);
-</pre>
-
-        <p><b>Effects:</b> Associates mutex <code>mx</code> with <code>
-        *this</code>. Calls <code>timed_lock</code>( <code>xt</code>)</p>
-        <hr>
-<pre>
-    scoped_timed_lock(TimedMutex&amp; mx, bool initially_locked);
-</pre>
-
-        <p><b>Effects:</b> Associates mutex <code>mx</code> with <code>
-        *this</code>. If <code>initially_locked</code> is <code>true</code>,
-        calls <code>lock()</code>.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~scoped_timed_lock();
-</pre>
-
-        <p><b>Effects:</b> If <code>locked()</code>, calls <code>
-        unlock()</code>. Destroys <code>*this</code>.</p>
-        <hr>
-
-        <h3>lock</h3>
-<pre>
-    void lock();
-</pre>
-
-        <p><b>Effects:</b> If the associated mutex is already locked by another
-        lock in the current thread, the effects depend on the locking strategy
-        of the associated mutex, as shown in the following table:</p>
-
-        <table summary="lock effects" border="1" cellpadding="5">
-            <tr>
-                <td><i><a href="mutex_concept.html#LockingStrategies">Locking
-                Strategy</a><br>
-                 of associated mutex</i></td>
-
-                <td><i>Effect if associated mutex is already locked by the
-                current thread</i></td>
-            </tr>
-
-            <tr>
-                <td>Recursive</td>
-
-                <td>As if an additional lock were added to the mutex.</td>
-            </tr>
-
-            <tr>
-                <td>Checked</td>
-
-                <td>Throws <a href="lock_error.html">lock_error</a>.</td>
-            </tr>
-
-            <tr>
-                <td>Unchecked</td>
-
-                <td>Undefined behavior [<a href="bibliography.html#ISO">ISO</a>
-                1.3.12] (but typically, <a href="definitions.html#Deadlock">
-                deadlock</a>.)</td>
-            </tr>
-        </table>
-
-        <p>If the associated mutex is already locked by some other thread,
-        places the current thread in the <a href="definitions.html#State">
-        Blocked</a> state until the associated mutex is unlocked, after which
-        the current thread is placed in the <a href="definitions.html#State">
-        Ready</a> state, eventually to be returned to the <a href=
-        "definitions.html#State">Running</a> state. Places the associated mutex
-        in the locked state.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        locked()</code> or as indicated in <b>Effects</b>.</p>
-        <hr>
-
-        <h3>timed_lock</h3>
-<pre>
-    bool timed_lock(const <a href="xtime.html">xtime</a>&amp; xt);
-</pre>
-
-        <p><b>Effects:</b> Same as <code>lock()</code>, except that if xt is
-        reached, places the current thread in the <a href=
-        "definitions.html#State">Ready</a> state without further ado.</p>
-
-        <p><b>Returns:</b> <code>locked()</code>.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        locked()</code> or as indicated in <b>Effects</b>.</p>
-        <hr>
-
-        <h3>unlock</h3>
-<pre>
-    void unlock();
-</pre>
-
-        <p><b>Effects:</b> Unlocks the associated mutex.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        !locked()</code>.</p>
-        <hr>
-
-        <h3>const void* Conversion</h3>
-<pre>
-    operator const void*() const;
-</pre>
-
-        <p><b>Returns:</b> If the associated mutex is currently locked, a value
-        convertible to <code>true</code>, else a value convertible to <code>
-        false</code>.</p>
-
-        <p><b>Rationale:</b> A <code>const void*</code> conversion is
-        considered safer than a conversion to <code>bool</code>.</p>
-        <hr>
-
-        <h3>locked</h3>
-<pre>
-    bool locked() const;
-</pre>
-
-        <p><b>Returns:</b> <code>this-&gt;operator const void*() !=
-        0</code>.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include &lt;boost/thread/mutex.hpp&gt;
-#include &lt;iostream&gt;
-
-int main(int, char*[])
-{
-   boost::timed_mutex mutex;
-   boost::xtime xt;
-   boost::get_xtime(&amp;xt, boost::TIME_UTC);
-   xt.sec += 1;
-   boost::mutex::scoped_timed_lock scope_timed_lock(mutex, xt);
-   if (scope_timed_lock.locked())
-      std::cout &lt;&lt; &quot;locked&quot; &lt;&lt; std::endl;
-   else
-      std::cout &lt;&lt; &quot;unlocked&quot; &lt;&lt; std::endl;
-   return 0;
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-locked
-</pre>
-        <hr>
-
-        <p>Revised 
-        <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%B %d, %Y" startspan -->November 05, 2001<!--webbot bot="Timestamp" endspan i-checksum="39585" --></p>
-
-        <p><i>&copy; Copyright <a href="mailto:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/scoped_try_lock.html

@@ -1,305 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, scoped_try_lock</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">scoped_try_lock</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>This class template defines a generic lock type which meets the <a
-        href="lock_concept.html#ScopedTryLock">ScopedTryLock</a> requirements.
-        The <a href="mutex.html">try_mutex</a>, <a href="mutex.html">
-        timed_mutex</a>, <a href="recursive_mutex.html">recursive_try_mutex</a>
-        and <a href="recursive_mutex.html">recursive_timed_mutex</a> classes
-        use this template to define their <code>scoped_try_lock</code>
-        types.</p>
-
-        <p>Like all the <b>Boost.Threads</b> <a href="lock_concept.html">lock
-        models</a>, <code>scoped_try_lock</code> objects are meant to be
-        short-lived. Objects of the class are not <a href=
-        "definitions.html#thread-safe">thread-safe</a>, and so should not be
-        shared between threads.</p>
-
-        <p>Class <code>scoped_try_lock</code> follows the &quot;resource
-        acquisition is initialization&quot; idiom <a href=
-        "bibliography.html#Stroustrup-00">[Stroustrup 00 14.4.1]</a> and is a
-        realization of the &quot;Scoped Locking Pattern&quot; <a href=
-        "bibliography.html#Schmidt-00">[Schmidt-00]</a>. Thus the usage is to
-        let the constructor do the locking, and then let the destructor do the
-        unlocking automatically at the end of the enclosing scope. The lock()
-        and unlock() members are usually not explicitly called, but are
-        provided to allow for complex overlapping locks of multiple
-        mutexes.</p>
-
-        <p>Although this class is an implementation detail, it is publicly
-        documented here because of its importance.</p>
-
-        <p>The type used to instantiate the class must meet the <a href=
-        "mutex_concept.html#TryMutex">TryMutex</a> requirements.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/detail/lock.hpp">&lt;boost/thread/detail/lock.hpp&gt;</a>
-    <i>This header is usually not included directly by programmers
-    because it is supplied by <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a> or
-    <a href=
-"../../../boost/thread/recursive_mutex.hpp">&lt;boost/thread/recursive_mutex.hpp&gt;</a></i>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost { namespace detail { namespace thread {
-    template &lt;typename TryMutex&gt;
-    class scoped_try_lock : private <a href=
-"../../utility/utility.htm#Class noncopyable">boost::noncopyable</a> // Exposition only.
-        // Class scoped_try_lock meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-    {
-    public:
-        typedef TryMutex mutex_type;
-        
-        explicit scoped_try_lock(TryMutex&amp; mx);
-        scoped_try_lock(TryMutex&amp; mx, bool initially_locked);
-        ~scoped_try_lock();
-        
-        void lock();
-        bool try_lock();
-        void unlock();
-        
-        operator const void*() const;
-    };
-} // namespace thread
-} // namespace detail    
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructors</h3>
-<pre>
-    explicit scoped_try_lock(TryMutex&amp; mx);
-</pre>
-
-        <p><b>Effects:</b> Associates mutex <code>mx</code> with <code>
-        *this</code>. Calls <code>try_lock()</code>.</p>
-        <hr>
-<pre>
-    scoped_try_lock(TryMutex&amp; mx, bool initially_locked);
-</pre>
-
-        <p><b>Effects:</b> Associates mutex <code>mx</code> with <code>
-        *this</code>. If <code>initially_locked</code> is <code>true,</code>
-        calls <code>lock()</code>.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~scoped_try_lock();
-</pre>
-
-        <p><b>Effects:</b> If <code>locked()</code>, calls <code>
-        unlock()</code>. Destroys <code>*this</code>.</p>
-        <hr>
-
-        <h3>lock</h3>
-<pre>
-    void lock();
-</pre>
-
-        <p><b>Effects:</b> If the associated mutex is already locked by another
-        lock in the current thread, the effects depend on the locking strategy
-        of the associated mutex, as shown in the following table:</p>
-
-        <table summary="lock effects" border="1" cellpadding="5" height="147">
-            <tr>
-                <td height="34"><i><a href=
-                "mutex_concept.html#LockingStrategies">Locking Strategy</a><br>
-                 of associated mutex</i></td>
-
-                <td height="34"><i>Effect if associated mutex is already locked
-                by the current thread</i></td>
-            </tr>
-
-            <tr>
-                <td height="19">Recursive</td>
-
-                <td height="19">As if an additional lock were added to the
-                mutex.</td>
-            </tr>
-
-            <tr>
-                <td height="19">Checked</td>
-
-                <td height="19">Throws <a href="lock_error.html">
-                lock_error</a>.</td>
-            </tr>
-
-            <tr>
-                <td height="19">Unchecked</td>
-
-                <td height="19">Undefined behavior [<a href=
-                "bibliography.html#ISO">ISO</a> 1.3.12] (but typically, <a
-                href="definitions.html#Deadlock">deadlock</a>.)</td>
-            </tr>
-        </table>
-
-        <p>If the associated mutex is already locked by some other thread,
-        places the current thread in the <a href="definitions.html#State">
-        Blocked</a> state until the associated mutex is unlocked, after which
-        the current thread is placed in the <a href="definitions.html#State">
-        Ready</a> state, eventually to be returned to the <a href=
-        "definitions.html#State">Running</a> state. Places the associated mutex
-        in the locked state.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        locked()</code> or as indicated in <b>Effects</b>.</p>
-        <hr>
-
-        <h3>try_lock</h3>
-<pre>
-    bool try_lock();
-</pre>
-
-        <p><b>Effects:</b> If the associated mutex is already locked by another
-        lock in the current thread, the effects depend on the locking strategy
-        of the associated mutex, as shown in the following table:</p>
-
-        <table summary="try_lock effects" border="1" cellpadding="5" height=
-        "147">
-            <tr>
-                <td height="34"><i><a href=
-                "mutex_concept.html#LockingStrategies">Locking Strategy</a><br>
-                 of associated mutex</i></td>
-
-                <td height="34"><i>Effect if associated mutex is already locked
-                by the current thread</i></td>
-            </tr>
-
-            <tr>
-                <td height="19">Recursive</td>
-
-                <td height="19">As if an additional lock were added to the
-                mutex.</td>
-            </tr>
-
-            <tr>
-                <td height="19">Checked</td>
-
-                <td height="19">Throws <a href="lock_error.html">
-                lock_error</a>.</td>
-            </tr>
-
-            <tr>
-                <td height="19">Unspecified</td>
-
-                <td height="19">Undefined behavior [<a href=
-                "bibliography.html#ISO">ISO</a> 1.3.12] (but typically, <a
-                href="definitions.html#Deadlock">deadlock</a>.)</td>
-            </tr>
-        </table>
-
-        <p>If the associated mutex is not already locked by some other thread,
-        locks the associated mutex and returns true, else returns false.</p>
-
-        <p><b>Returns:</b> See effects.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        locked()</code> or as indicated in <b>Effects</b>.</p>
-        <hr>
-
-        <h3>unlock</h3>
-<pre>
-    void unlock();
-</pre>
-
-        <p><b>Effects:</b> Unlocks the associated mutex.</p>
-
-        <p><b>Throws:</b> <a href="lock_error.html">lock_error</a> if <code>
-        !locked()</code>.</p>
-        <hr>
-
-        <h3>const void* Conversion</h3>
-<pre>
-    operator const void*() const;
-</pre>
-
-        <p><b>Returns:</b> If the associated mutex is currently locked, a value
-        convertible to <code>true</code>, else a value convertible to <code>
-        false</code>.</p>
-
-        <p><b>Rationale:</b> A <code>const void*</code> conversion is
-        considered safer than a conversion to <code>bool</code>.</p>
-        <hr>
-
-        <h3>locked</h3>
-<pre>
-    bool locked() const;
-</pre>
-
-        <p><b>Returns:</b> <code>this-&gt;operator const void*() !=
-        0</code>.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include <a href=
-"../../../boost/thread/mutex.hpp">&lt;boost/thread/mutex.hpp&gt;</a>
-#include &lt;iostream&gt;
-
-int main(int, char*[])
-{
-   boost::mutex mutex;
-   boost::mutex::try_lock lock(mutex);
-   if (lock)
-      std::cout &lt;&lt; &quot;locked&quot; &lt;&lt; std::endl;
-   else
-      std::cout &lt;&lt; &quot;unlocked&quot; &lt;&lt; std::endl;
-   return 0;
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-locked
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/styles.css

@@ -1,4 +0,0 @@
-PRE
-{
-    BACKGROUND-COLOR: lightcyan
-}

doc/thread-ref.xml

@@ -0,0 +1,266 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/thread.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="thread">
+		<purpose>
+			<para>The <classname>thread</classname> class represents threads of
+			execution, and provides the functionality to create and manage 
+			threads within the &Boost.Threads; library. See 
+			<xref linkend="threads.glossary"/> for a precise description of 
+			<link linkend="threads.glossary.thread">thread of execution</link>,
+			and for definitions of threading-related terms and of thread states such as 
+			<link linkend="threads.glossary.thread-state">blocked</link>.</para>
+		</purpose>
+
+		<description>
+			<para>A <link linkend="threads.glossary.thread">thread of execution</link>
+			has an initial function. For the program's initial thread, the initial 
+			function is <code>main()</code>. For other threads, the initial 
+			function is <code>operator()</code> of the function object passed to
+			the <classname>thread</classname> object's constructor.</para>
+
+			<para>A thread of execution  is said to be &quot;finished&quot; 
+			or to have &quot;finished execution&quot; when its initial function returns or 
+			is terminated. This includes completion of all thread cleanup 
+			handlers, and completion of the normal C++ function return behaviors,
+			such as destruction of automatic storage (stack) objects and releasing 
+			any associated implementation resources.</para>
+
+			<para>A thread object has an associated state which is either
+			&quot;joinable&quot; or &quot;non-joinable&quot;.</para>
+
+			<para>Except as described below, the policy used by an implementation
+			of &Boost.Threads; to schedule transitions between thread states is 
+			unspecified.</para>
+
+			<para><note>Just as the lifetime of a file may be different from the
+			lifetime of an <code>iostream</code> object which represents the file, the lifetime
+			of a thread of execution may be different from the 
+			<classname>thread</classname> object which represents the thread of 
+			execution. In particular, after a call to <code>join()</code>,
+			the thread of execution will no longer exist even though the 
+			<classname>thread</classname> object continues to exist until the 
+			end of its normal lifetime. The converse is also possible; if 
+			a <classname>thread</classname> object is destroyed without 
+			<code>join()</code> first having been called, the thread of execution 
+			continues until its initial function completes.</note></para>
+		</description>
+
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+
+		<constructor>
+			<effects>Constructs a <classname>thread</classname> object 
+			representing the current thread of execution.</effects>
+			
+			<postconditions><code>*this</code> is non-joinable.</postconditions>
+			
+			<notes><emphasis role="bold">Danger:</emphasis>
+			<code>*this</code> is valid only within the current thread.</notes>
+		</constructor>
+
+		<constructor specifiers="explicit">
+			<parameter name="threadfunc">
+				<paramtype>const boost::function0&lt;void&gt;&amp;</paramtype>
+			</parameter>
+			
+			<effects>
+				Starts a new thread of execution and constructs a 
+				<classname>thread</classname> object representing it. 
+				Copies <code>threadfunc</code> (which in turn copies
+				the function object wrapped by <code>threadfunc</code>) 
+				to an internal location which persists for the lifetime 
+				of the new thread of execution. Calls <code>operator()</code>
+				on the copy of the <code>threadfunc</code> function object 
+				in the new thread of execution.
+			</effects>
+			
+			<postconditions><code>*this</code> is joinable.</postconditions>
+
+			<throws><code>boost::thread_resource_error</code> if a new thread
+			of execution cannot be started.</throws>
+		</constructor>
+		
+		<destructor>
+			<effects>Destroys <code>*this</code>. The actual thread of 
+			execution may continue to execute after the 
+			<classname>thread</classname> object has been destroyed.
+			</effects>
+			
+			<notes>If <code>*this</code> is joinable the actual thread 
+			of execution becomes &quot;detached&quot;. Any resources used 
+			by the thread will be reclaimed when the thread of execution 
+			completes. To ensure such a thread of execution runs to completion
+			before the <classname>thread</classname> object is destroyed, call
+			<code>join()</code>.</notes>
+		</destructor>
+		
+		<method-group name="comparison">
+			<method name="operator==" cv="const">
+				<type>bool</type>
+				
+				<parameter name="rhs">
+					<type>const thread&amp;</type>
+				</parameter>
+				
+				<requires>The thread is non-terminated or <code>*this</code>
+				is joinable.</requires>
+				  
+				<returns><code>true</code> if <code>*this</code> and 
+				<code>rhs</code> represent the same thread of 
+				execution.</returns>
+			</method>
+			
+			<method name="operator!=" cv="const">
+				<type>bool</type>
+				
+				<parameter name="rhs">
+					<type>const thread&amp;</type>
+				</parameter>
+				
+				<requires>The thread is non-terminated or <code>*this</code>
+				is joinable.</requires>
+				  
+				<returns><code>!(*this==rhs)</code>.</returns>
+			</method>
+		</method-group>
+
+		<method-group name="modifier">
+			<method name="join">
+				<type>void</type>
+				
+				<requires><code>*this</code> is joinable.</requires>
+				  
+				<effects>The current thread of execution blocks until the 
+				initial function of the thread of execution represented by 
+				<code>*this</code> finishes and all resources are 
+				reclaimed.</effects>
+				
+				<postcondition><code>*this</code> is non-joinable.</postcondition>
+				
+				<notes>If <code>*this == thread()</code> the result is 
+				implementation-defined. If the implementation doesn't
+				detect this the result will be 
+				<link linkend="threads.glossary.deadlock">deadlock</link>.
+				</notes>
+			</method>
+		</method-group>
+
+		<method-group name="static">
+			<method name="sleep" specifiers="static">
+				<type>void</type>
+				
+				<parameter name="xt">
+					<paramtype>const <classname>xtime</classname>&amp;</paramtype>
+				</parameter>
+				
+				<effects>The current thread of execution blocks until 
+				<code>xt</code> is reached.</effects>
+			</method>
+			
+			<method name="yield" specifiers="static">
+				<type>void</type>
+
+				<effects>The current thread of execution is placed in the
+				<link linkend="threads.glossary.thread-state">ready</link> 
+				state.</effects>
+				
+				<notes>
+					<simpara>Allow the current thread to give up the rest of its 
+					time slice (or other scheduling quota) to another thread. 
+					Particularly useful in non-preemptive implementations.</simpara>
+				</notes>
+			</method>
+		</method-group>
+	</class>
+
+	<class name="thread_group">
+		<purpose>
+			The <classname>thread_group</classname> class provides a container
+			for easy grouping of threads to simplify several common thread 
+			creation and management idioms.
+		</purpose>
+
+		<inherit access="private">
+			<type><classname>boost::noncopyable</classname></type>
+			<purpose>Exposition only</purpose>
+		</inherit>
+
+
+		<constructor>
+			<effects>Constructs an empty <classname>thread_group</classname>
+			container.</effects>
+		</constructor>
+		
+		<destructor>
+			<effects>Destroys each contained thread object. Destroys <code>*this</code>.</effects>
+			
+			<notes>Behavior is undefined if another thread references 
+			<code>*this </code> during the execution of the destructor.
+			</notes>
+		</destructor>
+
+		<method-group name="modifier">
+			<method name="create_thread">
+				<type><classname>thread</classname>*</type>
+				
+				<parameter name="threadfunc">
+					<paramtype>const boost::function0&lt;void&gt;&amp;</paramtype>
+				</parameter>
+				
+				<effects>Creates a new <classname>thread</classname> object 
+				that executes <code>threadfunc</code> and adds it to the 
+				<code>thread_group</code> container object's list of managed
+				<classname>thread</classname> objects.</effects>
+				
+				<returns>Pointer to the newly created 
+				<classname>thread</classname> object.</returns>
+			</method>
+
+			<method name="add_thread">
+				<type>void</type>
+				
+				<parameter name="thrd">
+					<paramtype><classname>thread</classname>* thrd</paramtype>
+				</parameter>
+				
+				<effects>Adds <code>thrd</code> to the 
+				<classname>thread_group</classname> object's list of managed 
+				<classname>thread</classname> objects. The <code>thrd</code> 
+				object must have been allocated via <code>operator new</code> and will 
+				be deleted when the group is destroyed.</effects>
+			</method>
+
+			<method name="remove_thread">
+				<type>void</type>
+				
+				<parameter name="thrd">
+					<paramtype><classname>thread</classname>* thrd</paramtype>
+				</parameter>
+				
+				<effects>Removes <code>thread</code> from <code>*this</code>'s
+				list of managed <classname>thread</classname> objects.</effects>
+				
+				<throws><emphasis role="bold">???</emphasis> if 
+				<code>thrd</code> is not in <code>*this</code>'s list
+				of managed <classname>thread</classname> objects.</throws>
+			</method>
+
+			<method name="join_all">
+				<type>void</type>
+				
+				<effects>Calls <code>join()</code> on each of the managed 
+				<classname>thread</classname> objects.</effects>
+			</method>
+		</method-group>
+	</class>
+  </namespace>
+</header>

doc/thread.html

@@ -1,262 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content=
-        "threads, Boost.Threads, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, thread</title>
-    </head>
-
-    <body bgcolor="#ffffff" link="#0000ff" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img height="86" alt="C++ Boost" src=
-                    "../../../c++boost.gif" width="277"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">Class thread</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>thread</code> class represents threads of execution, and
-        provides the functionality to create and manage threads within the <b>
-        Boost.Threads</b> library. See <a href="definitions.html">
-        Definitions</a> for a precise description of &quot;thread of
-        execution&quot;, and for definitions of threading related terms and of
-        thread states such as &quot;blocked&quot;.</p>
-
-        <p>A thread of execution has an initial function. For the program&#39;s
-        initial thread, the initial function is <code>main()</code>. For other
-        threads, the initial function is <code>operator()</code> of the
-        function object passed to the class <code>thread</code>
-        constructor.</p>
-
-        <p>A thread of execution is said to be &quot;finished&quot; or
-        &quot;finished execution&quot; when its initial function returns or is
-        terminated. This includes completion of all thread cleanup handlers,
-        and completion of the normal C++ function return behaviors, such as
-        destruction of automatic storage (stack) objects and releasing any
-        associated implementation resources.</p>
-
-        <p>A thread object has an associated state which is either
-        &quot;joinable&quot; or &quot;non-joinable&quot;.</p>
-
-        <p>Except as described below, the policy used by an implementation of
-        <b>Boost.Threads</b> to schedule transitions between thread states is
-        unspecified.</p>
-
-        <p><b>Note:</b> Just as the lifetime of a file may be different from
-        the lifetime of an iostream object which represents the file, the
-        lifetime of a thread of execution may be different from the <code>
-        thread</code> object which represents the thread of execution. In
-        particular, after a call to <code>join()</code>, the thread of
-        execution will no longer exist even though the <code>thread</code>
-        object continues to exist until the end of its normal lifetime. The
-        converse is also possible; if a <code>thread</code> object is destroyed
-        without <code>join()</code> having first been called, the thread of
-        execution continues until its initial function completes.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost {
-
-class thread : <a href=
-"../../utility/utility.htm#noncopyable">boost::noncopyable</a> // Exposition only.
-   // Class thread meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-{
-public:
-    thread();
-    explicit thread(const boost::function0&lt;void&gt;&amp; threadfunc);
-    ~thread();
-
-    bool operator==(const thread&amp; rhs) const;
-    bool operator!=(const thread&amp; rhs) const;
-
-    void join();
-
-    static void sleep(const xtime&amp; xt);
-    static void yield();
-};
-
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructors</h3>
-<pre>
-    thread();
-</pre>
-
-        <p><b>Effects:</b> Constructs a <code>thread</code> object representing
-        the current thread of execution.</p>
-
-        <p><b>Postcondition:</b> <code>*this</code> is non-joinable.</p>
-
-        <p><b>Danger:</b> <code>*this</code> is valid only within the current
-        thread.</p>
-<pre>
-    thread(const <a href=
-"../../function/index.html">boost::function0</a>&lt;void&gt;&amp; threadfunc);
-</pre>
-
-        <p><b>Effects:</b> Starts a new thread of execution and constructs a
-        <code>thread</code> object representing it. Copies <code>
-        threadfunc</code> (which in turn copies the function object wrapped by
-        <code>threadfunc</code>) to an internal location which persists for the
-        lifetime of the new thread of execution. Calls <code>operator()</code>
-        on the copy of the <code>threadfunc</code> function object in the new
-        thread of execution.</p>
-
-        <p><b>Postcondition:</b> <code>*this</code> is joinable.</p>
-
-        <p><b>Throws:</b> <code>boost::thread_resource_error</code> if a new
-        thread of execution cannot be started.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~thread();
-</pre>
-
-        <p><b>Effects:</b> Destroys <code>*this</code>. The actual thread of
-        execution may continue to execute after the <code>thread</code> object
-        has been destroyed.</p>
-
-        <p><b>Notes:</b> If <code>*this</code> is joinable the actual thread of
-        execution becomes &quot;detached&quot;. Any resources used by the
-        thread will be reclaimed when the thread of execution completes. To
-        ensure such a thread of execution runs to completion before the <code>
-        thread</code> object is destroyed, call <code>join()</code>.</p>
-        <hr>
-
-        <h3>Comparison Operators</h3>
-<pre>
-    bool operator==(const thread&amp; rhs);
-</pre>
-
-        <p><b>Requires:</b> The thread is non-terminated or <code>*this</code>
-        is joinable.</p>
-
-        <p><b>Returns:</b> <code>true</code> if <code>*this</code> and <code>
-        rhs</code> represent the same thread of execution.</p>
-<pre>
-    bool operator!=(const thread&amp; rhs);
-</pre>
-
-        <p><b>Returns:</b> <code>!(*this==rhs)</code>.</p>
-        <hr>
-
-        <h3>join</h3>
-<pre>
-    void join();
-</pre>
-
-        <p><b>Requires:</b> <code>*this</code> is joinable.</p>
-
-        <p><b>Effects:</b> The current thread of execution blocks until the
-        initial function of the thread of execution represented by <code>
-        *this</code> finishes and all resources are reclaimed.</p>
-
-        <p><b>Postcondition:</b> <code>*this</code> is non-joinable.</p>
-
-        <p><b>Note:</b> If <code>*this == thread()</code> the result is
-        implementation defined. If the implementation doesn&#39;t detect this
-        the result will be <a href="definitions.html#Deadlock">
-        deadlock</a>.</p>
-        <hr>
-
-        <h3>sleep</h3>
-<pre>
-    static void sleep(const <a href="xtime.html">xtime</a>&amp; xt);
-</pre>
-
-        <p><b>Effects:</b> The current thread of execution blocks until <code>
-        xt</code> is reached.</p>
-        <hr>
-
-        <h3>yield</h3>
-<pre>
-    static void yield();
-</pre>
-
-        <p><b>Effects:</b> The current thread of execution is placed in the
-        &quot;ready&quot; state.</p>
-
-        <p><b>Notes:</b> Allow the current thread to give up the rest of its
-        time slice (or other scheduling quota) to another thread. Particularly
-        useful in non-preemptive implementations.</p>
-        <hr>
-
-        <h2><a name="Example">Example Usage</a></h2>
-<pre>
-#include &lt;boost/thread/thread.hpp&gt;
-#include &lt;iostream&gt;
-
-struct thread_alarm
-{
-   thread_alarm(int secs) : m_secs(secs) { }
-   void operator()()
-   {
-       boost::xtime xt;
-       boost::xtime_get(&amp;xt, boost::TIME_UTC);
-       xt.sec += m_secs;
-
-       boost::thread::sleep(xt);
-
-       std::cout &lt;&lt; &quot;alarm sounded...&quot; &lt;&lt; std::endl;
-   }
-
-   int m_secs;
-};
-
-int main(int argc, char* argv[])
-{
-   int secs = 5;
-   std::cout &lt;&lt; &quot;setting alarm for 5 seconds...&quot; &lt;&lt; std::endl;
-   thread_alarm alarm(secs);
-   boost::thread thrd(alarm);
-   thrd.join();
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-setting alarm for 5 seconds...
-alarm sounded...
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/thread.xml

@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<library name="Threads" dirname="thread" id="threads"
+last-revision="$Date$"
+xmlns:xi="http://www.w3.org/2001/XInclude">
+  <libraryinfo>
+    <author>
+      <firstname>William</firstname>
+	  <othername>E.</othername>
+      <surname>Kempf</surname>
+    </author>
+
+    <copyright>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>William E. Kempf</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>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.</para>
+    </legalnotice>
+
+    <librarypurpose>Portable C++ multi-threading</librarypurpose>
+
+    <librarycategory name="category:concurrent" />
+
+    <title>Boost.Threads</title>
+  </libraryinfo>
+  <title>&Boost.Threads;</title>
+  <xi:include href="overview.xml"/>
+  <xi:include href="design.xml"/>
+  <xi:include href="concepts.xml"/>
+  <xi:include href="rationale.xml"/>
+  <xi:include href="reference.xml"/>
+  <xi:include href="faq.xml"/>
+  <xi:include href="configuration.xml"/>
+  <xi:include href="build.xml"/>
+  <xi:include href="implementation_notes.xml"/>
+  <xi:include href="release_notes.xml"/>
+  <xi:include href="glossary.xml"/>
+  <xi:include href="acknowledgements.xml"/>
+  <xi:include href="bibliography.xml"/>
+</library>

doc/thread_group.html

@@ -1,182 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, thread_group</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">thread_group</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <tt>thread_group</tt> class provides a container for easy
-        grouping of threads to simplify several common thread creation and
-        management idioms.</p>
-
-        <p>All <tt>thread_group</tt> member functions are <a href=
-        "definitions.html#thread-safe">thread-safe</a>, except destruction.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class thread_group : <a href=
-"../../utility/utility.htm#noncopyable">boost::noncopyable</a>
-    {
-    public:
-        thread_group();
-        ~thread_group();
-
-        thread* create_thread(const boost::function0&lt;void&gt;&amp; threadfunc);
-        void add_thread(thread* thrd);
-        void remove_thread(thread* thrd);
-        void join_all();
-    };
-}
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    thread_group();
-</pre>
-
-        <p><b>Effects:</b> Constructs an empty <tt>thread_group</tt>
-        container.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-    ~thread_group();
-</pre>
-
-        <p><b>Effects:</b> Destroys each contained thread object. Destroys
-        <code>*this</code>.</p>
-
-        <p><b>Notes:</b> Behavior is undefined if another thread references
-        *this during the execution of the destructor.</p>
-        <hr>
-
-        <h3>create_thread</h3>
-<pre>
-    thread* create_thread(const boost::function0&lt;void&gt;&amp; threadfunc);
-</pre>
-
-        <p><b>Effects:</b> Creates a new <tt>thread</tt> object that executes
-        <tt>threadfunc</tt> and adds it to the <tt>thread_group</tt> container
-        object&#39;s list of managed <tt>thread</tt> objects.</p>
-
-        <p><b>Returns:</b> Pointer to the newly created thread.</p>
-        <hr>
-
-        <h3>add_thread</h3>
-<pre>
-    void add_thread(thread* thrd);
-</pre>
-
-        <p><b>Effects:</b> Adds <tt>thrd</tt> to the <tt>thread_group</tt>
-        object&#39;s list of managed <tt>thread</tt> objects. The <tt>thrd</tt>
-        object must have been allocated via operator new and will be deleted
-        when the group is destroyed.</p>
-        <hr>
-
-        <h3>remove_thread</h3>
-<pre>
-    void remove_thread(thread* thrd);
-</pre>
-
-        <p><b>Effects:</b> Removes <code>*this</code>&#39;s list of managed
-        <tt>thread</tt> objects.</p>
-
-        <p><b>Throws:</b> ? if <tt>thrd</tt> is not it <code>*this</code>&#39;s
-        list of managed <tt>thread</tt> objects.</p>
-        <hr>
-
-        <h3>join_all</h3>
-<pre>
-    void join_all();
-</pre>
-
-        <p><b>Effects:</b> Calls <code>join()</code> on each of the managed
-        <tt>thread</tt> objects.</p>
-        <hr>
-
-        <h2><a name="Example">Example</a> Usage</h2>
-<pre>
-#include &lt;boost/thread/thread.hpp&gt;
-#include &lt;iostream&gt;
-
-int count = 0;
-boost::mutex mutex;
-
-void increment_count()
-{
-   boost::mutex::lock lock(mutex);
-   std::cout &lt;&lt; &quot;count = &quot; &lt;&lt; ++count &lt;&lt; std::endl;
-}
-
-int main(int argc, char* argv[])
-{
-   boost::thread_group threads;
-   for (int i = 0; i &lt; 10; ++i)
-      threads.create_thread(&amp;increment_count);
-   threads.join_all();
-}
-</pre>
-
-        <p>The output is:</p>
-<pre>
-count = 1
-count = 2
-count = 3
-count = 4
-count = 5
-count = 6
-count = 7
-count = 8
-count = 9
-count = 10
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/thread_pool-ref.xml

@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/thread_pool.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <class name="thread_pool">
+	</class>
+  </namespace>
+</header>

doc/thread_pool.html

@@ -0,0 +1,207 @@
+<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 - Header &lt;boost/thread/thread_pool.hpp&gt;</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">Header &lt;<a href="../../../boost/thread/thread_pool.hpp">boost/thread/thread_pool.hpp</a>&gt;</h2>
+    </td>
+  </tr>
+</table>
+<hr>
+<h2>Contents</h2>
+<dl class="page-index"> 
+  <dt><a href="#introduction">Introduction</a></dt>
+  <dt><a href="#classes">Classes</a></dt>
+  <dl class="page-index">
+    <dt><a href="#class-thread_pool">Class <code>thread_pool</code></a></dt>
+	<dl class="page-index">
+	  <dt><a href="#class-thread_pool-synopsis">Class <code>thread_pool</code> synopsis</a></dt>
+	  <dt><a href="#class-thread_pool-ctors">Class <code>thread_pool</code> constructors and destructor</a></dt>
+  	  <dt><a href="#class-thread_pool-modifiers">Class <code>thread_pool</code> modifier functions</a></dt>
+	</dl>
+  </dl>
+  <dt><a href="#examples">Example(s)</a></dt>
+</dl>
+<hr>
+<h2><a name="introduction"></a>Introduction</h2>
+<p>Include the header &lt;<a href="../../../boost/thread/thread_pool.hpp">boost/thread/thread_pool.hpp</a>&gt; 
+  to define the <a href="#class-thread_pool">thread_pool</a> class.</p>
+<h2><a name="classes"></a>Classes</h2>
+<h3><a name="class-thread_pool"></a>Class <code>thread_pool</code></h3>
+		
+<p>The <tt>thread_pool</tt> class provides&nbsp;an interface for&nbsp;running 
+  jobs on a dynamically managed set&nbsp;of worker threads called a pool.&nbsp; 
+  When a job is added, it can execute on any&nbsp;available thread in the pool.&nbsp; 
+  This class controls&nbsp;both the maximum and minimum number of threads&nbsp;in 
+  the pool.&nbsp; If a thread in the pool is sitting idle&nbsp;for a period&nbsp;of 
+  time, it&nbsp;will exit unless by exiting the number of threads would dip below 
+  the minimum. Thread pools provide an optimization over creating a new thread 
+  for each job since the pool can often remove the overhead of thread creation.</p>
+<h4><a name="class-thread_pool-synopsis"></a>Class <code>thread_pool</code> synopsis</h4>
+<pre>
+namespace boost
+{
+    class thread_pool : <a href="../../utility/utility.htm#Class noncopyable">boost::noncopyable</a> // Exposition only.
+        // Class thread meets the <a href="overview.html#non-copyable">NonCopyable</a> requirement.
+    {
+    public:
+        thread_pool(int max_threads=std::numeric_limits&lt;int&gt;::max(), 
+                    int min_threads=0,
+                    int timeout_secs=5); 
+        ~thread_pool();
+
+        void add(const boost::function0&lt;void&gt; &amp;job);
+        void join();
+        void cancel();
+        void detach();
+    };
+};
+</pre>
+<h4><a name="class-spec-ctors"></a>Class <code>thread_pool</code> constructors and destructor</h4>
+<pre>
+thread_pool(int max_threads=std::numeric_limits&lt;int&gt;::max(), 
+            int min_threads=0,
+            int timeout_secs=5);
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Constructs a thread pool object and starts min_threads threads 
+			running in the pool.</dt>
+</dl>
+<pre>
+~thread_pool();
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Calls join() if neither join() nor detach() were called 
+			previously for this thread_pool.&nbsp; If detach() was not called, destroys all 
+			resources associated with the threads in the pool and with the queue of jobs 
+			still waiting to be executed.</dt>
+</dl>
+<h4><a name="class-spec-modifiers"></a>Class <code>thread_pool</code> modifier 
+  functions</h4>
+<pre>
+void add(const boost::function0&lt;void&gt;&amp; job);
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Adds <tt>job</tt> to the <tt>thread_pool</tt> object's list of 
+			jobs waiting to be executed.&nbsp; If any threads in the pool are idle, the job 
+			will be execute as soon as the idle thread is scheduled by the operating 
+			system.&nbsp; If no threads are idle and the number of threads in the pool is 
+			less than the maximum number provided to the constructor, an additional thread 
+			is created and added to the pool.&nbsp; That new thread will execute this job 
+			as soon as it is scheduled by the operating system.&nbsp; If no threads are 
+			idle and&nbsp;the thread count is at the maximum, this job will be queued until 
+			a thread becomes available.&nbsp; Currently, queued jobs are processed in FIFO 
+			order.</dt>
+  <dt><b>Throws:</b> std::runtime_error if join() or detach() have 
+		previously been called for this thread_pool object.</dt>
+</dl>
+<pre>
+void detach();
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Relinquishes control of the pool of threads by this thread_pool 
+			object.&nbsp; Any threads in the pool will continue to run and continue to 
+			process any queued jobs, but no new threads will be created, and any subsequent 
+			attempts to add new jobs will result in an exception.</dt>
+  <dt><b>Throws:</b> std::runtime_error if join()&nbsp;has previously 
+			been called for this thread_pool object.</dt>
+</dl>
+<pre>
+void cancel();
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Removes all queued jobs from the thread_pool's internal queue, 
+			and calls cancel() on all boost::thread objects in the pool.&nbsp; The specific 
+			behavior of those threads will be dictated by their cancellation behavior - the 
+			pool threads may be executing a user's job that deferrs cancellation, for 
+			example.</dt>
+  <dt><b>Throws:</b> std::runtime_error if join() or detach() have 
+			previously been called for this thread_pool object.</dt>
+  <dt><b>Note:</b> for the current version (1.27.0) of Boost.Threads, thread::cancel() is 
+			not provided.&nbsp; This function -will- clear out all queued jobs, but any 
+			currently executing jobs will not be cancelled.</dt>
+</dl>
+<pre>
+void join();
+</pre>
+<dl class="function-semantics"> 
+  <dt><b>Effects:</b> Waits until all queued jobs are completed by the thread pool, 
+			and then join()s will all of the threads in the pool.&nbsp; When join() 
+			returns, no running threads will remain in the pool, and this object is invalid 
+			for anything except destruction.&nbsp; Any calls to cancel(), join(), detach(), 
+			or add() will result in an exception.</dt>
+</dl>
+<h2><a name="examples"></a>Example(s)</h2>
+		<pre>
+#include &lt;boost/thread/thread_pool.hpp&gt; 
+#include &lt;boost/thread/mutex.hpp&gt; 
+#include &lt;iostream&gt; 
+
+boost::mutex io_mutex; 
+
+class job_adapter {
+public: 
+    job_adapter(void (*func)(int), int param) :
+_func(func), _param(param){ }
+        void operator()() const { _func(_param); }
+private:
+   void (*_func)(int);
+   int _param; 
+}; 
+   
+void simple_job(int param) 
+{ 
+    boost::mutex::scoped_lock l(io_mutex); 
+    std::cout &lt;&lt; param &lt;&lt; " squared is " &lt;&lt; (param*param) &lt;&lt; "\n";
+} 
+
+int main(int argc, char* argv[]) 
+{ 
+    boost::thread_pool tp;
+    for (int i = 1; i &lt;= 10; ++i) 
+        tp.add(simple_job); 
+    tp.join();
+	return 0;
+}
+</pre>
+		<p>Typical output would be:</p>
+		<pre>
+1 squared is 1
+2 squared is 4
+3 squared is 9
+4 squared is 16
+5 squared is 25
+7 squared is 49
+6 squared is 36
+8 squared is 64
+10 squared is 100
+9 squared is 81
+</pre>
+		<P>While the jobs are dispatched in the order they are received, the scheduling of 
+			the individual threads in the pool is platform-dependent.</P>
+		<P>
+<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>, David Moore 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>

doc/thread_resource_error.html

@@ -1,78 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content="threads, BTL, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, thread_resource_error</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0" width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">thread_resource_error</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-        <a href="#Header">Header</a><br>
-        <a href="#Synopsis">Synopsis</a><br>
-        <a href="#Members">Members</a><br>
-        <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>thread_resource_error</code> class defines an exception
-        type that is thrown by constructors in the <b>Boost.Threads</b> library
-        when thread related resources can not be acquired. This does not
-        include memory allocation failures which instead throw
-        std::bad_alloc.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/exceptions.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost
-{
-    class thread_resource_error : public std::runtime_error
-    {
-    public:
-       thread_resource_error();
-    };
-}
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-    thread_resource_error();
-</pre>
-
-        <p>Constructs a <code>thread_resource_error</code> object.</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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/thread_specific_ptr.html

@@ -1,223 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content=
-        "threads, Boost.Threads, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, thread_specific_ptr</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">thread_specific_ptr</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Members">Members</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>thread_specific_ptr</code> class defines an interface for
-        using thread specific storage. Thread specific storage is data
-        associated with individual threads and is often used to make operations
-        <a href="definitions.html#Thread-safe">thread-safe</a> that rely on
-        global data.</p>
-
-        <p>Template <code>thread_specific_ptr</code> stores a pointer to an
-        object obtained via <code>new</code> on a thread-by-thread basis and
-        calls delete on the contained pointer when the thread terminates. Each
-        thread initially stores the null pointer in each <code>
-        thread_specific_ptr</code> instance.</p>
-
-        <p>The template <code>thread_specific_ptr</code> is useful in the
-        following cases:</p>
-
-        <ul>
-            <li>An interface was original written assuming a single thread of
-            control and is being ported to a multi-threaded environment.</li>
-
-            <li>Each thread of control invokes sequences of methods that share
-            data that must be logically accessed through a globally visible
-            access point, but are physically unique for each thread, instead of
-            being explicitly passed.</li>
-        </ul>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/tss.hpp">&lt;boost/thread/tss.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost {
-
-template &lt;typename T&gt;
-class thread_specific_ptr : private boost::noncopyable // Exposition only.
-    // Class thread_specific_ptr meets the <a href=
-"overview.html#NonCopyable">NonCopyable</a> requirement.
-{
-public:
-    thread_specific_ptr();
-    ~thread_specific_ptr();
-
-    T* get() const;
-    T* operator-&gt;() const;
-    T&amp; operator*() const;
-    T* release();
-    void reset(T* p=0);
-};
-
-} // namespace boost
-</pre>
-
-        <h2><a name="Members">Members</a></h2>
-        <hr>
-
-        <h3>Constructor</h3>
-<pre>
-   thread_specific_ptr();
-</pre>
-
-        <p><b>Postconditions:</b> A thread specific storage has been reserved
-        for use by *this in all threads, with each thread initially storing a
-        null pointer.</p>
-
-        <p><b>Requires:</b> The expression <code>delete get()</code> is well
-        formed.</p>
-
-        <p><b>Throws:</b> <code>boost::thread_resource_error</code> if the
-        necessary resources can not be obtained.</p>
-
-        <p><b>Notes:</b> There is an implementation specific limit to the
-        number of thread specific storage objects that can be created, and this
-        limit may be small.</p>
-        <hr>
-
-        <h3>Destructor</h3>
-<pre>
-   ~thread_specific_ptr();
-</pre>
-
-        <p><b>Notes:</b> Does not destroy any data that may be stored in any
-        thread&#39;s thread specific storage. For this reason you should not
-        destroy a <code>thread_specific_ptr</code> object until you are certain
-        there are no threads running that have made use of its thread specific
-        storage.</p>
-        <hr>
-
-        <h3>get</h3>
-<pre>
-   T* get() const;
-</pre>
-
-        <p><b>Returns:</b> The object stored in thread specific storage for the
-        current thread for *this.</p>
-
-        <p><b>Notes:</b> Each thread initially returns 0.</p>
-        <hr>
-
-        <h3>Smart Pointer Operations</h3>
-<pre>
-   T* operator-&gt;() const;
-</pre>
-
-        <p><b>Returns:</b> <code>get()</code></p>
-<pre>
-   T&amp; operator*() const;
-</pre>
-
-        <p><b>Returns:</b> <code>get()</code></p>
-
-        <p><b>Requires:</b> <code>get() != 0</code></p>
-        <hr>
-
-        <h3>Release</h3>
-<pre>
-   T* release();
-</pre>
-
-        <p><b>Returns:</b> <code>get()</code></p>
-
-        <p><b>Postcondition:</b> *this holds the null pointer for the current
-        thread.</p>
-        <hr>
-
-        <h3>Reset</h3>
-<pre>
-   void reset(T* p=0);
-</pre>
-
-        <p><b>Effects:</b> If <code>get()!= p</code> then <code>delete
-        get()</code>.</p>
-
-        <p><b>Postconditions:</b> <code>*this</code> holds the pointer <code>
-        p</code> for the current thread.</p>
-
-        <p><b>Notes:</b> The pointer will be deleted when the thread
-        terminates.</p>
-        <hr>
-
-        <h2><a name="Example">Example Usage</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/tss.hpp">&lt;boost/thread/tss.hpp&gt;</a>
-#include &lt;cassert&gt;
-
-boost::thread_specific_ptr&lt;int&gt; value;
-
-void increment()
-{
-   int* p = value.get();
-   ++*p;
-}
-
-void thread_proc()
-{
-   value.reset(new int(0)); // initialize the thread&#39;s storage
-   for (int i=0; i&lt;10; ++i)
-   {
-       increment();
-       int* p = value.get();
-       assert(*p == i+1);
-   }
-}
-
-int main(int argc, char* argv[])
-{
-   boost::thread_group threads;
-   for (int i=0; i&lt;5; ++i)
-      threads.create_thread(&amp;thread_proc);
-   threads.join_all();
-}
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

doc/tss-ref.xml

@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/tss.hpp"
+	last-revision="$Date$">
+	<namespace name="boost">
+		<class name="thread_specific_ptr">
+			<purpose>
+				The <classname>thread_specific_ptr</classname> class defines 
+				an interface for using thread specific storage.
+			</purpose>
+			
+			<description>
+				<para>Thread specific storage is data associated with 
+				individual threads and is often used to make operations
+				that rely on global data 
+				<link linkend="threads.glossary.thread-safe">thread-safe</link>.
+				</para>
+				
+				<para>Template <classname>thread_specific_ptr</classname> 
+				stores a pointer to an object obtained on a thread-by-thread
+				basis and calls a specified cleanup handler on the contained
+				pointer when the thread terminates. The cleanup handlers are
+				called in the reverse order of construction of the 
+				<classname>thread_specific_ptr</classname>s, and for the 
+				initial thread are called by the destructor, providing the 
+				same ordering guarantees as for normal declarations. Each
+				thread initially stores the null pointer in each
+				<classname>thread_specific_ptr</classname> instance.</para>
+				
+				<para>The template <classname>thread_specific_ptr</classname>
+				is useful in the following cases:
+					<itemizedlist>
+						<listitem>An interface was originally written assuming 
+						a single thread of control and it is being ported to a
+						multithreaded environment.</listitem>
+						
+						<listitem>Each thread of control invokes sequences of
+						methods that share data that are physically unique
+						for each thread, but must be logically accessed
+						through a globally visible access point instead of 
+						being explicitly passed.</listitem>
+					</itemizedlist>
+				</para>
+			</description>
+			
+			<inherit access="private">
+				<type><classname>boost::noncopyable</classname></type>
+				<purpose>Exposition only</purpose>
+			</inherit>
+			
+			<constructor>
+				<requires>The expression <code>delete get()</code> is well
+				formed.</requires>
+				
+				<effects>A thread-specific data key is allocated and visible to
+				all threads in the process. Upon creation, the value 
+				<code>NULL</code> will be associated with the new key in all 
+				active threads. A cleanup method is registered with the key 
+				that will call <code>delete</code> on the value associated 
+				with the key for a thread when it exits. When a thread exits,
+				if a key has a registered cleanup method and the thread has a
+				non-<code>NULL</code> value associated with that key, the value
+				of the key is set to <code>NULL</code> and then the cleanup 
+				method is called with the previously associated value as its 
+				sole argument. The order in which registered cleanup methods 
+				are called when a thread exits is undefined. If after all the
+				cleanup methods have been called for all non-<code>NULL</code>
+				values, there are still some non-<code>NULL</code> values
+				with associated cleanup handlers the result is undefined
+				behavior.</effects>
+				
+				<throws><classname>boost::thread_resource_error</classname> if
+				the necessary resources can not be obtained.</throws>
+				
+				<notes>There may be an implementation specific limit to the 
+				number of thread specific storage objects that can be created,
+				and this limit may be small.</notes>
+				
+				<rationale>The most common need for cleanup will be to call 
+				<code>delete</code> on the associated value. If other forms
+				of cleanup are required the overloaded constructor should be
+				called instead.</rationale>
+			</constructor>
+			
+			<constructor>
+				<parameter name="cleanup">
+					<paramtype>void (*cleanup)(void*)</paramtype>
+				</parameter>
+				
+				<effects>A thread-specific data key is allocated and visible to
+				all threads in the process. Upon creation, the value 
+				<code>NULL</code> will be associated with the new key in all 
+				active threads. The <code>cleanup</code> method is registered
+				with the key and will be called for a thread with the value 
+				associated with the key for that thread when it exits. When a
+				thread exits, if a key has a registered cleanup method and the
+				thread has a non-<code>NULL</code> value associated with that
+				key, the value of the key is set to <code>NULL</code> and then
+				the cleanup method is called with the previously associated
+				value as its sole argument. The order in which registered
+				cleanup methods are called when a thread exits is undefined.
+				If after all the cleanup methods have been called for all 
+				non-<code>NULL</code> values, there are still some 
+				non-<code>NULL</code> values with associated cleanup handlers
+				the result is undefined behavior.</effects>
+				
+				<throws><classname>boost::thread_resource_error</classname> if
+				the necessary resources can not be obtained.</throws>
+				
+				<notes>There may be an implementation specific limit to the 
+				number of thread specific storage objects that can be created,
+				 and this limit may be small.</notes>
+				 
+				 <rationale>There is the occasional need to register 
+				 specialized cleanup methods, or to register no cleanup method
+				 at all (done by passing <code>NULL</code> to this constructor.
+				 </rationale>
+			</constructor>
+			
+			<destructor>
+				<effects>Deletes the thread-specific data key allocated by the
+				constructor. The thread-specific data values associated with
+				the key need not be <code>NULL</code>. It is the responsibility
+				of the application to perform any cleanup actions for data
+				associated with the key.</effects>
+				
+				<notes>Does not destroy any data that may be stored in any
+				thread's thread specific storage. For this reason you should
+				not destroy a <classname>thread_specific_ptr</classname> object
+				until you are certain there are no threads running that have
+				made use of its thread specific storage.</notes>
+				
+				<rationale>Associated data is not cleaned up because registered
+				cleanup methods need to be run in the thread that allocated the
+				associated data to be guarranteed to work correctly. There's no
+				safe way to inject the call into another thread's execution
+				path, making it impossible to call the cleanup methods safely.
+				</rationale>
+			</destructor>
+			
+			<method-group name="modifier functions">
+				<method name="release">
+					<type>T*</type>
+					
+					<postconditions><code>*this</code> holds the null pointer
+					for the current thread.</postconditions>
+					
+					<returns><code>this-&gt;get()</code> prior to the call.</returns>
+					
+					<rationale>This method provides a mechanism for the user to
+					relinquish control of the data associated with the 
+					thread-specific key.</rationale>
+				</method>
+			
+				<method name="reset">
+					<type>void</type>
+
+					<parameter name="p">
+						<paramtype>T*</paramtype>
+						<default>0</default>
+					</parameter>
+					
+					<effects>If <code>this-&gt;get() != p &amp;&amp; 
+					this-&gt;get() != NULL</code> then call the 
+					associated cleanup function.</effects>
+					
+					<postconditions><code>*this</code> holds the pointer 
+					<code>p</code> for the current thread.</postconditions>
+				</method>
+			</method-group>
+			
+			<method-group name="observer functions">
+				<method name="get" cv="const">
+					<type>T*</type>
+					
+					<returns>The object stored in thread specific storage for
+					the current thread for <code>*this</code>.</returns>
+					
+					<notes>Each thread initially returns 0.</notes>
+				</method>
+				
+				<method name="operator-&gt;" cv="const">
+					<type>T*</type>
+					
+					<returns><code>this-&gt;get()</code>.</returns>
+				</method>
+				
+				<method name="operator*()" cv="const">
+					<type>T&amp;</type>
+					
+					<requires><code>this-&gt;get() != 0</code></requires>
+					
+					<returns><code>this-&gt;get()</code>.</returns>
+				</method>
+			</method-group>
+		</class>
+	</namespace>
+</header>

doc/xtime-ref.xml

@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
+  "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd" [
+  <!ENTITY % threads.entities SYSTEM "entities.xml">
+  %threads.entities;
+]>
+<header name="boost/thread/xtime.hpp"
+  last-revision="$Date$">
+  <namespace name="boost">
+    <enum name="xtime_clock_types">
+		<enumvalue name="TIME_UTC" />
+
+		<purpose>
+			<para>Specifies the clock type to use when creating
+			an object of type <classname>xtime</classname>.</para>
+		</purpose>
+
+		<description>
+			<para>The only clock type supported by &Boost.Threads; is 
+			<code>TIME_UTC</code>. The epoch for <code>TIME_UTC</code>
+			is 1970-01-01 00:00:00.</para>
+		</description>
+	</enum>
+
+    <struct name="xtime">
+		<purpose>
+			<simpara>An object of type <classname>xtime</classname>
+			defines a time that is used to perform high-resolution time operations.
+			This is a temporary solution that will be replaced by a more robust time 
+			library once available in Boost.</simpara>
+		</purpose>
+
+		<description>
+			<simpara>The <classname>xtime</classname> type is used to represent a point on 
+			some time scale or a duration in time. This type may be proposed for the C standard by 
+			Markus Kuhn. &Boost.Threads; provides only a very minimal implementation of this
+			proposal; it is expected that a full implementation (or some other time
+			library) will be provided in Boost as a separate library, at which time &Boost.Threads;
+			will deprecate its own implementation.</simpara>
+			
+			<simpara><emphasis role="bold">Note</emphasis> that the resolution is 
+			implementation specific. For many implementations the best resolution 
+			of time is far more than one nanosecond, and even when the resolution 
+			is reasonably good, the latency of a call to <code>xtime_get()</code>
+			may be significant. For maximum portability, avoid durations of less than
+			one second.</simpara>
+		</description>
+
+		<free-function-group name="creation">
+			<function name="xtime_get">
+				<type>int</type>
+				
+				<parameter name="xtp">
+					<paramtype><classname>xtime</classname>*</paramtype>
+				</parameter>
+
+				<parameter name="clock_type">
+					<paramtype>int</paramtype>
+				</parameter>
+				
+				<postconditions>
+					<simpara><code>xtp</code> represents the current point in
+					time as a duration since the epoch specified by
+					<code>clock_type</code>.</simpara>
+				</postconditions>
+				
+				<returns>
+					<simpara><code>clock_type</code> if successful, otherwise 0.</simpara>
+				</returns>
+			</function>
+		</free-function-group>
+
+		<data-member name="sec">
+			<type><emphasis>platform-specific-type</emphasis></type>
+		</data-member>
+	</struct>
+  </namespace>
+</header>

doc/xtime.html

@@ -1,147 +0,0 @@
-<html>
-    <head>
-        <meta http-equiv="Content-Type" content=
-        "text/html; charset=iso-8859-1">
-        <meta name="keywords" content=
-        "threads, Boost.Threads, thread library, C++">
-        <link rel="stylesheet" type="text/css" href="styles.css">
-
-        <title>Boost.Threads, xtime</title>
-    </head>
-
-    <body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
-        <table summary="header" border="0" cellpadding="7" cellspacing="0"
-        width="100%">
-            <tr>
-                <td valign="top" width="300">
-                    <h3><img src="../../../c++boost.gif" alt="C++ Boost" width=
-                    "277" height="86"></h3>
-                </td>
-
-                <td valign="top">
-                    <h1 align="center">Boost.Threads</h1>
-
-                    <h2 align="center">xtime</h2>
-                </td>
-            </tr>
-        </table>
-        <hr>
-
-        <p><a href="#Introduction">Introduction</a><br>
-         <a href="#Header">Header</a><br>
-         <a href="#Synopsis">Synopsis</a><br>
-         <a href="#Reference">Reference</a><br>
-         <a href="#Example">Example</a></p>
-
-        <h2><a name="Introduction">Introduction</a></h2>
-
-        <p>The <code>xtime</code> type is used to represent a point on some
-        time scale or a duration in time. This type may be proposed for the C
-        standard by Markus Kuhn. <b>Boost.Threads</b> provides only a very
-        minimal implementation of this proposal and it&#39;s expected that a
-        full implementation will be provided in Boost as a separate library, at
-        which time <b>Boost.Threads</b> will deprecate its implementation.</p>
-
-        <h2><a name="Header">Header</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/xtime.hpp">&lt;boost/thread/xtime.hpp&gt;</a>
-</pre>
-
-        <h2><a name="Synopsis">Synopsis</a></h2>
-<pre>
-namespace boost {
-
-enum
-{
-   TIME_UTC=1,
-};
-
-struct xtime
-{
-#if defined(BOOST_NO_INT64_T)
-   int_fast32_t sec;
-#else
-   int_fast64_t sec;
-#endif
-   int_fast32_t nsec;
-};
-
-int xtime_get(struct xtime* xtp, int clock_type);
-
-} // namespace boost
-</pre>
-
-        <h2><a name="Reference">Reference</a></h2>
-        <hr>
-
-        <h3>TIME_UTC</h3>
-
-        <p>The clock type for Coordinated Universal Time (UTC). The epoch for
-        this clock type is 1970-01-01 00:00:00. This is the only clock type
-        supported by <b>Boost.Threads</b>.</p>
-        <hr>
-
-        <h3>xtime</h3>
-<pre>
-   struct xtime
-   {
-#if defined(BOOST_NO_INT64_T)
-      int_fast32_t sec;
-#else
-      int_fast64_t sec;
-#endif
-      int_fast32_t nsec;
-   };
-</pre>
-
-        <p><b>sec</b> represents the whole seconds that have passed since the
-        epoch.</p>
-
-        <p><b>nsec</b> represents the nanoseconds since <code>sec.</code></p>
-        <hr>
-
-        <h3>xtime_get</h3>
-<pre>
-   int xtime_get(struct xtime* xtp, int clock_type);
-</pre>
-
-        <p><b>Postcondition:</b> <code>xtp</code> represents the current point
-        in time as a duration since the epoch specified by the <code>
-        clock_type</code>.</p>
-
-        <p><b>Returns:</b> <code>clock_type</code> if successful, otherwise
-        0.</p>
-
-        <p><b>Notes:</b> The resolution is implementation specific. For many
-        implementations the best resolution of time is far more than one
-        nanosecond, and even when the resolution is reasonably good, the
-        latency of a call to <code>xtime_get()</code> may be significant. For
-        maximum portability, avoid durations of less than one second.</p>
-        <hr>
-
-        <h2><a name="Example">Example Usage</a></h2>
-<pre>
-#include <a href=
-"../../../boost/thread/thread.hpp">&lt;boost/thread/thread.hpp&gt;</a>
-#include <a href=
-"../../../boost/thread/tss.hpp">&lt;boost/thread/xtime.hpp&gt;</a>
-
-int main(int argc, char* argv[])
-{
-   boost::xtime xt;
-   boost::xtime_get(&amp;xt, boost::TIME_UTC);
-   xt.sec += 1;
-   boost::thread::sleep(xt); // Sleep for 1 second
-}
-</pre>
-        <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:williamkempf@hotmail.com">
-        William E. Kempf</a> 2001 all rights reserved.</i></p>
-    </body>
-</html>
-

example/.cvsignore

@@ -0,0 +1,2 @@
+bin
+*.pdb

example/Jamfile

@@ -1,66 +1,54 @@
-#  (C) Copyright William E. Kempf 2001. Permission to copy, use, modify, sell and
-#  distribute this software is granted provided this copyright notice appears
-#  in all copies. This software is provided "as is" without express or implied
-#  warranty, and with no claim as to its suitability for any purpose.
+# Copyright (C) 2001-2003
+# William E. Kempf
 #
-# Boost.Threads build and test Jamfile
+# 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.
 #
-# Declares the following targets:
-#   1. monitor, an example program.
-#   2. starvephil, an example program.
-#   3. tennis, an example program.
+# Boost.Threads example Jamfile
+#
+# Additional configuration variables used:
+#   1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32
+#      library should be used instead of "native" threads. This feature is
+#      mostly used for testing and it's generally recommended you use the
+#      native threading libraries instead. PTW32 should be set to be a list
+#      of two strings, the first specifying the installation path of the
+#      pthreads-win32 library and the second specifying which library
+#      variant to link against (see the pthreads-win32 documentation).
+#      Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib"
 
-# declare the location of this subproject relative to the root
+# Declare the location of this subproject relative to the root.
 subproject libs/thread/example ;
 
-# Do some OS-specific setup
-if $(NT)
+# Include threads.jam for Boost.Threads global build information.
+# This greatly simplifies the Jam code needed to configure the build
+# for the various Win32 build types.
+import ../build/threads ;
+
 {
-    BOOST_THREADMON_LIB = <lib>../build/libboost_threadmon ;
+    template example
+        ## sources ##
+        : <template>thread_base
+          <dll>../build/boost_thread
+        ## requirements ##
+        :
+        ## default build ##
+        :
+    ;
+
+    exe monitor : <template>example monitor.cpp ;
+    exe starvephil : <template>example starvephil.cpp ;
+    exe tennis : <template>example tennis.cpp ;
+    exe condition : <template>example condition.cpp ;
+    exe mutex : <template>example mutex.cpp ;
+    exe once : <template>example once.cpp ;
+    exe recursive_mutex : <template>example recursive_mutex.cpp ;
+    exe thread : <template>example thread.cpp ;
+    exe thread_group : <template>example thread_group.cpp ;
+    exe tss : <template>example tss.cpp ;
+    exe xtime : <template>example xtime.cpp ;
 }
-else
-{
-    BOOST_THREADMON_LIB = ;
-}
-
-#######################
-
-#
-# Declare the Boost.Threads monitor example program.
-#
-
-exe monitor : monitor/monitor.cpp
-    <lib>../build/libboost_thread
-	$(BOOST_THREADMON_LIB)
-    # requirements
-    : <include>$(BOOST_ROOT)
-    <threading>multi
-    : debug release ;
-
-#######################
-
-#
-# Declare the Boost.Threads starvephil example program.
-#
-
-exe starvephil : starvephil/starvephil.cpp
-    <lib>../build/libboost_thread
-	$(BOOST_THREADMON_LIB)
-    # requirements
-    : <include>$(BOOST_ROOT)
-    <threading>multi
-    : debug release ;
-
-#######################
-
-#
-# Declare the Boost.Threads tennis example program.
-#
-
-exe tennis : tennis/tennis.cpp
-    <lib>../build/libboost_thread
-	$(BOOST_THREADMON_LIB)
-    # requirements
-    : <include>$(BOOST_ROOT)
-    <threading>multi
-    : debug release ;

example/Jamfile.v2

@@ -0,0 +1,5 @@
+
+exe starvephil 
+    : starvephil.cpp ../build/boost_thread  ../../test/build/unit_test_framework 
+    ;
+

example/condition.cpp

@@ -0,0 +1,79 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <iostream>
+#include <vector>
+#include <boost/utility.hpp>
+#include <boost/thread/condition.hpp>
+#include <boost/thread/thread.hpp>
+
+class bounded_buffer : private boost::noncopyable
+{
+public:
+    typedef boost::mutex::scoped_lock lock;
+
+    bounded_buffer(int n) : begin(0), end(0), buffered(0), circular_buf(n) { }
+
+    void send (int m) {
+        lock lk(monitor);
+        while (buffered == circular_buf.size())
+            buffer_not_full.wait(lk);
+        circular_buf[end] = m;
+        end = (end+1) % circular_buf.size();
+        ++buffered;
+        buffer_not_empty.notify_one();
+    }
+    int receive() {
+        lock lk(monitor);
+        while (buffered == 0)
+            buffer_not_empty.wait(lk);
+        int i = circular_buf[begin];
+        begin = (begin+1) % circular_buf.size();
+        --buffered;
+        buffer_not_full.notify_one();
+        return i;
+    }
+
+private:
+    int begin, end, buffered;
+    std::vector<int> circular_buf;
+    boost::condition buffer_not_full, buffer_not_empty;
+    boost::mutex monitor;
+};
+
+bounded_buffer buf(2);
+
+void sender() {
+    int n = 0;
+    while (n < 100) {
+        buf.send(n);
+        std::cout << "sent: " << n << std::endl;
+        ++n;
+    }
+    buf.send(-1);
+}
+
+void receiver() {
+    int n;
+    do {
+        n = buf.receive();
+        std::cout << "received: " << n << std::endl;
+    } while (n != -1); // -1 indicates end of buffer
+}
+
+int main(int, char*[])
+{
+    boost::thread thrd1(&sender);
+    boost::thread thrd2(&receiver);
+    thrd1.join();
+    thrd2.join();
+    return 0;
+}

example/monitor.cpp

@@ -1,3 +1,14 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
 #include <vector>
 #include <iostream>
 #include <boost/thread/condition.hpp>
@@ -6,9 +17,9 @@
 #include <boost/thread/thread.hpp>
 
 namespace {
-    const int ITERS = 100;
-    boost::mutex io_mutex;
-}
+const int ITERS = 100;
+boost::mutex io_mutex;
+} // namespace
 
 template <typename M>
 class buffer_t

example/monitor/Carbon.r

@@ -1 +0,0 @@
-/*

example/mutex.cpp

@@ -0,0 +1,52 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/mutex.hpp>
+#include <boost/thread/thread.hpp>
+#include <iostream>
+
+boost::mutex io_mutex; // The iostreams are not guaranteed to be thread-safe!
+
+class counter
+{
+public:
+    counter() : count(0) { }
+
+    int increment() {
+        boost::mutex::scoped_lock scoped_lock(mutex);
+        return ++count;
+    }
+
+private:
+    boost::mutex mutex;
+    int count;
+};
+
+counter c;
+
+void change_count()
+{
+    int i = c.increment();
+    boost::mutex::scoped_lock scoped_lock(io_mutex);
+    std::cout << "count == " << i << std::endl;
+}
+
+int main(int, char*[])
+{
+    const int num_threads = 4;
+    boost::thread_group thrds;
+    for (int i=0; i < num_threads; ++i)
+        thrds.create_thread(&change_count);
+
+    thrds.join_all();
+
+    return 0;
+}

example/once.cpp

@@ -0,0 +1,36 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/thread.hpp>
+#include <boost/thread/once.hpp>
+#include <cassert>
+
+int value=0;
+boost::once_flag once = BOOST_ONCE_INIT;
+
+void init()
+{
+    ++value;
+}
+
+void thread_proc()
+{
+    boost::call_once(&init, once);
+}
+
+int main(int argc, char* argv[])
+{
+    boost::thread_group threads;
+    for (int i=0; i<5; ++i)
+        threads.create_thread(&thread_proc);
+    threads.join_all();
+    assert(value == 1);
+}

example/recursive_mutex.cpp

@@ -0,0 +1,54 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/recursive_mutex.hpp>
+#include <boost/thread/thread.hpp>
+#include <iostream>
+
+class counter
+{
+public:
+    counter() : count(0) { }
+
+    int add(int val) {
+        boost::recursive_mutex::scoped_lock scoped_lock(mutex);
+        count += val;
+        return count;
+    }
+    int increment() {
+        boost::recursive_mutex::scoped_lock scoped_lock(mutex);
+        return add(1);
+    }
+
+private:
+    boost::recursive_mutex mutex;
+    int count;
+};
+
+counter c;
+
+void change_count()
+{
+    std::cout << "count == " << c.increment() << std::endl;
+}
+
+int main(int, char*[])
+{
+    const int num_threads=4;
+
+    boost::thread_group threads;
+    for (int i=0; i < num_threads; ++i)
+        threads.create_thread(&change_count);
+
+    threads.join_all();
+
+    return 0;
+}

example/starvephil.cpp

@@ -1,3 +1,14 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
 #include <boost/thread/mutex.hpp>
 #include <boost/thread/condition.hpp>
 #include <boost/thread/thread.hpp>
@@ -7,7 +18,7 @@
 
 namespace
 {
-    boost::mutex iomx;
+boost::mutex iomx;
 }
 
 class canteen
@@ -39,8 +50,9 @@ public:
         boost::mutex::scoped_lock lock(m_mutex);
         {
             boost::mutex::scoped_lock lock(iomx);
-            std::cout << "(" << clock() <<
-                ") Chef: ouch ... make room ... this dish is very hot ..." << std::endl;
+            std::cout << "(" << clock()
+                      << ") Chef: ouch ... make room ... this dish is "
+                      << "very hot ..." << std::endl;
         }
         boost::xtime xt;
         boost::xtime_get(&xt, boost::TIME_UTC);
@@ -84,7 +96,7 @@ void chef()
         {
             boost::mutex::scoped_lock lock(iomx);
             std::cout << "(" << clock() << ") Chef: " << chickens
-                << " chickens, ready-to-go ..." << std::endl;
+                      << " chickens, ready-to-go ..." << std::endl;
         }
         g_canteen.put(chickens);
     }
@@ -96,7 +108,8 @@ struct phil
     void run() {
         {
             boost::mutex::scoped_lock lock(iomx);
-            std::cout << "(" << clock() << ") Phil" << m_id << ": starting ..." << std::endl;
+            std::cout << "(" << clock() << ") Phil" << m_id
+                      << ": starting ..." << std::endl;
         }
         for (;;)
         {
@@ -110,13 +123,13 @@ struct phil
             {
                 boost::mutex::scoped_lock lock(iomx);
                 std::cout << "(" << clock() << ") Phil" << m_id
-                    << ": gotta eat ..." << std::endl;
+                          << ": gotta eat ..." << std::endl;
             }
             g_canteen.get(m_id);
             {
                 boost::mutex::scoped_lock lock(iomx);
                 std::cout << "(" << clock() << ") Phil" << m_id
-                    << ": mmm ... that's good ..." << std::endl;
+                          << ": mmm ... that's good ..." << std::endl;
             }
         }
     }
@@ -129,7 +142,10 @@ struct phil
 
 struct thread_adapt
 {
-    thread_adapt(void (*func)(void*), void* param) : _func(func), _param(param) { }
+    thread_adapt(void (*func)(void*), void* param)
+        : _func(func), _param(param)
+    {
+    }
     int operator()() const
     {
         _func(_param);
@@ -143,7 +159,10 @@ struct thread_adapt
 class thread_adapter
 {
 public:
-    thread_adapter(void (*func)(void*), void* param) : _func(func), _param(param) { }
+    thread_adapter(void (*func)(void*), void* param)
+        : _func(func), _param(param)
+    {
+    }
     void operator()() const { _func(_param); }
 private:
     void (*_func)(void*);

example/starvephil/Carbon.r

@@ -1 +0,0 @@
-/*

example/tennis.cpp

@@ -1,3 +1,14 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
 #include <boost/thread/mutex.hpp>
 #include <boost/thread/condition.hpp>
 #include <boost/thread/thread.hpp>
@@ -49,7 +60,10 @@ void player(void* param)
         {
             cond.wait(lock);
             if (state == other)
-                std::cout << "---" << player_name(active) << ": Spurious wakeup!" << std::endl;
+            {
+                std::cout << "---" << player_name(active)
+                          << ": Spurious wakeup!" << std::endl;
+            }
         } while (state == other);
     }
 
@@ -60,7 +74,10 @@ void player(void* param)
 
 struct thread_adapt
 {
-    thread_adapt(void (*func)(void*), void* param) : _func(func), _param(param) { }
+    thread_adapt(void (*func)(void*), void* param)
+        : _func(func), _param(param)
+    {
+    }
     int operator()() const
     {
         _func(_param);
@@ -74,7 +91,10 @@ struct thread_adapt
 class thread_adapter
 {
 public:
-    thread_adapter(void (*func)(void*), void* param) : _func(func), _param(param) { }
+    thread_adapter(void (*func)(void*), void* param)
+        : _func(func), _param(param)
+    {
+    }
     void operator()() const { _func(_param); }
 private:
     void (*_func)(void*);

example/tennis/Carbon.r

@@ -1 +0,0 @@
-/*

example/thread.cpp

@@ -0,0 +1,40 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/thread.hpp>
+#include <boost/thread/xtime.hpp>
+#include <iostream>
+
+struct thread_alarm
+{
+    thread_alarm(int secs) : m_secs(secs) { }
+    void operator()()
+    {
+        boost::xtime xt;
+        boost::xtime_get(&xt, boost::TIME_UTC);
+        xt.sec += m_secs;
+
+        boost::thread::sleep(xt);
+
+        std::cout << "alarm sounded..." << std::endl;
+    }
+
+    int m_secs;
+};
+
+int main(int argc, char* argv[])
+{
+    int secs = 5;
+    std::cout << "setting alarm for 5 seconds..." << std::endl;
+    thread_alarm alarm(secs);
+    boost::thread thrd(alarm);
+    thrd.join();
+}

example/thread_group.cpp

@@ -0,0 +1,30 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/thread.hpp>
+#include <iostream>
+
+int count = 0;
+boost::mutex mutex;
+
+void increment_count()
+{
+    boost::mutex::scoped_lock lock(mutex);
+    std::cout << "count = " << ++count << std::endl;
+}
+
+int main(int argc, char* argv[])
+{
+    boost::thread_group threads;
+    for (int i = 0; i < 10; ++i)
+        threads.create_thread(&increment_count);
+    threads.join_all();
+}

example/tss.cpp

@@ -0,0 +1,41 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/thread.hpp>
+#include <boost/thread/tss.hpp>
+#include <cassert>
+
+boost::thread_specific_ptr<int> value;
+
+void increment()
+{
+    int* p = value.get();
+    ++*p;
+}
+
+void thread_proc()
+{
+    value.reset(new int(0)); // initialize the thread's storage
+    for (int i=0; i<10; ++i)
+    {
+        increment();
+        int* p = value.get();
+        assert(*p == i+1);
+    }
+}
+
+int main(int argc, char* argv[])
+{
+    boost::thread_group threads;
+    for (int i=0; i<5; ++i)
+        threads.create_thread(&thread_proc);
+    threads.join_all();
+}

example/xtime.cpp

@@ -0,0 +1,21 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#include <boost/thread/thread.hpp>
+#include <boost/thread/xtime.hpp>
+
+int main(int argc, char* argv[])
+{
+    boost::xtime xt;
+    boost::xtime_get(&xt, boost::TIME_UTC);
+    xt.sec += 1;
+    boost::thread::sleep(xt); // Sleep for 1 second
+}

include/boost/thread/barrier.hpp

@@ -0,0 +1,40 @@
+// Copyright (C) 2002-2003
+// David Moore, William E. Kempf
+//
+// 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.
+
+#ifndef BOOST_BARRIER_JDM030602_HPP
+#define BOOST_BARRIER_JDM030602_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+#include <boost/thread/mutex.hpp>
+#include <boost/thread/condition.hpp>
+
+namespace boost {
+
+class BOOST_THREAD_DECL barrier
+{
+public:
+    barrier(unsigned int count);
+    ~barrier();
+
+    bool wait();
+
+private:
+    mutex m_mutex;
+    condition m_cond;
+    unsigned int m_threshold;
+    unsigned int m_count;
+    unsigned int m_generation;
+};
+
+}   // namespace boost
+
+#endif

include/boost/thread/condition.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,10 +12,7 @@
 #ifndef BOOST_CONDITION_WEK070601_HPP
 #define BOOST_CONDITION_WEK070601_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
 #include <boost/thread/exceptions.hpp>
 #include <boost/utility.hpp>
@@ -31,15 +28,61 @@ namespace boost {
 
 struct xtime;
 
-class condition : private noncopyable
+namespace detail {
+
+class BOOST_THREAD_DECL condition_impl : private noncopyable
 {
+    friend class condition;
+
 public:
-    condition();
-    ~condition();
+    condition_impl();
+    ~condition_impl();
 
     void notify_one();
     void notify_all();
 
+#if (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
+    void enter_wait();
+    void do_wait();
+    bool do_timed_wait(const xtime& xt);
+#elif defined(BOOST_HAS_PTHREADS)
+    void do_wait(pthread_mutex_t* pmutex);
+    bool do_timed_wait(const xtime& xt, pthread_mutex_t* pmutex);
+#endif
+
+#if defined(BOOST_HAS_WINTHREADS)
+    void* m_gate;
+    void* m_queue;
+    void* m_mutex;
+    unsigned m_gone;  // # threads that timed out and never made it to m_queue
+    unsigned long m_blocked; // # threads blocked on the condition
+    unsigned m_waiting; // # threads no longer waiting for the condition but
+                        // still waiting to be removed from m_queue
+#elif defined(BOOST_HAS_PTHREADS)
+    pthread_cond_t m_condition;
+#elif defined(BOOST_HAS_MPTASKS)
+    MPSemaphoreID m_gate;
+    MPSemaphoreID m_queue;
+    threads::mac::detail::scoped_critical_region m_mutex;
+    threads::mac::detail::scoped_critical_region m_mutex_mutex;
+    unsigned m_gone; // # threads that timed out and never made it to m_queue
+    unsigned long m_blocked; // # threads blocked on the condition
+    unsigned m_waiting; // # threads no longer waiting for the condition but
+                        // still waiting to be removed from m_queue
+#endif
+};
+
+} // namespace detail
+
+class condition : private noncopyable
+{
+public:
+    condition() { }
+    ~condition() { }
+
+    void notify_one() { m_impl.notify_one(); }
+    void notify_all() { m_impl.notify_all(); }
+
     template <typename L>
     void wait(L& lock)
     {
@@ -84,79 +127,63 @@ public:
     }
 
 private:
+    detail::condition_impl m_impl;
+
     template <typename M>
     void do_wait(M& mutex)
     {
 #if (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
-        enter_wait();
+        m_impl.enter_wait();
 #endif
 
-        typedef typename detail::thread::lock_ops<M> lock_ops;
-        lock_ops::lock_state state;
+        typedef detail::thread::lock_ops<M>
+#if defined(__HP_aCC) && __HP_aCC <= 33900 && !defined(BOOST_STRICT_CONFIG)
+# define lock_ops lock_ops_  // HP confuses lock_ops witht the template
+#endif
+            lock_ops;
+
+        typename lock_ops::lock_state state;
         lock_ops::unlock(mutex, state);
 
 #if defined(BOOST_HAS_PTHREADS)
-        do_wait(state.pmutex);
+        m_impl.do_wait(state.pmutex);
 #elif (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
-        do_wait();
+        m_impl.do_wait();
 #endif
 
         lock_ops::lock(mutex, state);
+#undef lock_ops
     }
 
     template <typename M>
     bool do_timed_wait(M& mutex, const xtime& xt)
     {
 #if (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
-        enter_wait();
+        m_impl.enter_wait();
 #endif
 
-        typedef typename detail::thread::lock_ops<M> lock_ops;
-        lock_ops::lock_state state;
+        typedef detail::thread::lock_ops<M>
+#if defined(__HP_aCC) && __HP_aCC <= 33900 && !defined(BOOST_STRICT_CONFIG)
+# define lock_ops lock_ops_  // HP confuses lock_ops witht the template
+#endif
+            lock_ops;
+
+        typename lock_ops::lock_state state;
         lock_ops::unlock(mutex, state);
 
         bool ret = false;
 
 #if defined(BOOST_HAS_PTHREADS)
-        ret = do_timed_wait(xt, state.pmutex);
+        ret = m_impl.do_timed_wait(xt, state.pmutex);
 #elif (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
-        ret = do_timed_wait(xt);
+        ret = m_impl.do_timed_wait(xt);
 #endif
 
         lock_ops::lock(mutex, state);
+#undef lock_ops
 
         return ret;
     }
-
-#if (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
-    void enter_wait();
-    void do_wait();
-    bool do_timed_wait(const xtime& xt);
-#elif defined(BOOST_HAS_PTHREADS)
-    void do_wait(pthread_mutex_t* pmutex);
-    bool do_timed_wait(const xtime& xt, pthread_mutex_t* pmutex);
-#endif
-
-#if defined(BOOST_HAS_WINTHREADS)
-    void* m_gate;
-    void* m_queue;
-    void* m_mutex;
-    unsigned m_gone; // # threads that timed out and never made it to the m_queue
-    unsigned long m_blocked; // # threads m_blocked m_waiting for the condition
-    unsigned m_waiting; // # threads m_waiting no longer m_waiting for the condition but still
-                      //   m_waiting to be removed from the m_queue
-#elif defined(BOOST_HAS_PTHREADS)
-    pthread_cond_t m_condition;
-#elif defined(BOOST_HAS_MPTASKS)
-    MPSemaphoreID m_gate;
-    MPSemaphoreID m_queue;
-    threads::mac::detail::scoped_critical_region m_mutex;
-    threads::mac::detail::scoped_critical_region m_mutex_mutex;
-    unsigned m_gone; // # threads that timed out and never made it to the m_queue
-    unsigned long m_blocked; // # threads m_blocked m_waiting for the condition
-    unsigned m_waiting; // # threads m_waiting no longer m_waiting for the condition but still
-                      //   m_waiting to be removed from the m_queue
-#endif
 };
 
 } // namespace boost
@@ -164,7 +191,8 @@ private:
 // Change Log:
 //    8 Feb 01  WEKEMPF Initial version.
 //   22 May 01  WEKEMPF Modified to use xtime for time outs.
-//   23 May 01  WEKEMPF Removed "duration" timed_waits, as they are too difficult
-//                      to use with spurious wakeups.
+//   23 May 01  WEKEMPF Removed "duration" timed_waits, as they are too
+//                      difficult to use with spurious wakeups.
+//    3 Jan 03  WEKEMPF Modified for DLL implementation.
 
 #endif // BOOST_CONDITION_WEK070601_HPP

include/boost/thread/config.hpp

@@ -1,100 +0,0 @@
-// Copyright (C) 2001
-// William E. Kempf
-//
-// 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.
-
-// This file is used to configure Boost.Threads during development
-// in order to decouple dependency on any Boost release.  Once
-// accepted into Boost these contents will be moved to <boost/config>
-// or some other appropriate build configuration and all
-// #include <boost/thread/config.hpp> statements will be changed
-// accordingly.
-
-#ifndef BOOST_THREAD_CONFIG_WEK070601_HPP
-#define BOOST_THREAD_CONFIG_WEK070601_HPP
-
-#include <boost/config.hpp>
-
-#error "Included <boost/thread/config.hpp>"
-
-/*// Define if threading support is enabled for the toolset.
-#undef BOOST_HAS_THREADS
-
-// Define if threading should be implemented in terms of Win32 threads.
-#undef BOOST_HAS_WINTHREADS
-
-// Define if threading should be implemented in terms of POSIX threads.
-#undef BOOST_HAS_PTHREADS
-
-// Define if BOOST_HAS_PTHREADS and pthread_delay_np() exists.
-#undef BOOST_HAS_PTHREAD_DELAY_NP
-
-// Define if BOOST_HAS_PTHREADS and not BOOST_HAS_PTHREAD_DELAY_NP
-// but nanosleep can be used instead.
-#undef BOOST_HAS_NANOSLEEP
-
-// Define if BOOST_HAS_PTHREADS and pthread_yield() exists.
-#undef BOOST_HAS_PTHREAD_YIELD
-
-// Define if BOOST_HAS_PTHREADS and not BOOST_HAS_PTHREAD_YIELD and
-// sched_yield() exists.
-#undef BOOST_HAS_SCHED_YIELD
-
-// Define if gettimeofday() exists.
-#undef BOOST_HAS_GETTIMEOFDAY
-
-// Define if not BOOST_HAS_GETTIMEOFDAY and clock_gettime() exists.
-#undef BOOST_HAS_CLOCK_GETTIME
-
-// Define if not BOOST_HAS_GETTIMEOFDAY and not BOOST_HAS_CLOCK_GETTIME and
-// GetSystemTimeAsFileTime() can be called with an FTIME structure.
-#undef BOOST_HAS_FTIME
-
-// Define if pthread_mutexattr_settype and pthread_mutexattr_gettype exist.
-#undef BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
-
-// Here we'll set up known compiler options.
-
-#if defined(BOOST_MSVC)
-#   if defined(_MT)
-#       define BOOST_HAS_THREADS
-#   endif
-#   define BOOST_HAS_WINTHREADS // comment out this to test pthreads-win32.
-#   if !defined(BOOST_HAS_WINTHREADS)
-#       define BOOST_HAS_PTHREADS
-#       define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
-#       define PtW32NoCatchWarn
-#       pragma comment(lib, "pthreadVCE.lib")
-#   endif
-#   define BOOST_HAS_FTIME
-    //  pdm: this is for linux - is there a better #define to #if on?
-    //  wek: not sure how else to do this, but GNU CC on Win32 should probably
-    //       use BOOST_HAS_WINTHREADS, and I expect there will be other
-    //       platform specific variations for this compiler toolset.  Need
-    //       to decide how to handle this.
-#elif defined( __GNUC__ )
-#   define BOOST_HAS_THREADS
-#   define BOOST_HAS_PTHREADS
-#   define BOOST_HAS_NANOSLEEP
-#   define BOOST_HAS_GETTIMEOFDAY
-    //  pdm: From the pthread.h header, one of these macros
-    //  must be defined for this stuff to exist.
-    //  wek: This seems like a harmless enough method to determine these
-    //       switches, but one should note that some implementations may not
-    //       use these.  Notably, pthreads-win32 doesn't define either
-    //       __USE_UNIX98 or __USE_GNU.
-#   if defined( __USE_UNIX98 )
-#       define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
-#   elif defined( __USE_GNU )
-#       define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
-#       define BOOST_HAS_PTHREAD_YIELD
-#   endif
-#endif*/
-
-#endif // BOOST_THREAD_CONFIG_WEK070601_HPP

include/boost/thread/detail/config.hpp

@@ -0,0 +1,60 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP
+#define BOOST_THREAD_CONFIG_WEK01032003_HPP
+
+#include <boost/config.hpp>
+
+// insist on threading support being available:
+#include <boost/config/requires_threads.hpp>
+
+#if defined(BOOST_HAS_WINTHREADS)
+#   if defined(BOOST_THREAD_BUILD_DLL) //Build dll
+#       define BOOST_THREAD_DECL __declspec(dllexport)
+#   elif defined(BOOST_THREAD_BUILD_LIB) //Build lib
+#       define BOOST_THREAD_DECL
+#   elif defined(BOOST_THREAD_USE_LIB) //Use lib
+#       define BOOST_THREAD_DECL
+#   else //Use dll
+#       define BOOST_THREAD_DECL __declspec(dllimport)
+#       define BOOST_DYN_LINK
+#   endif
+#else
+#   define BOOST_THREAD_DECL
+#   if defined(BOOST_THREAD_USE_LIB) //Use lib
+#   else //Use dll
+#       define BOOST_DYN_LINK
+#   endif
+#endif // BOOST_HAS_WINTHREADS
+
+//
+// Automatically link to the correct build variant where possible. 
+// 
+#if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) && !defined(BOOST_THREAD_BUILD_LIB)
+//
+// Set the name of our library, this will get undef'ed by auto_link.hpp
+// once it's done with it:
+//
+#if defined(BOOST_THREAD_LIB_NAME)
+#    define BOOST_LIB_NAME BOOST_THREAD_LIB_NAME
+#else
+#    define BOOST_LIB_NAME boost_thread
+#endif
+//
+// If we're importing code from a dll, then tell auto_link.hpp about it:
+//
+// And include the header that does the work:
+//
+#include <boost/config/auto_link.hpp>
+#endif  // auto-linking disabled
+
+#endif // BOOST_THREAD_CONFIG_WEK1032003_HPP

include/boost/thread/detail/force_cast.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // Mac Murrett
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -14,31 +14,30 @@
 #ifndef BOOST_FORCE_CAST_MJM012402_HPP
 #define BOOST_FORCE_CAST_MJM012402_HPP
 
+#include <boost/thread/detail/config.hpp>
+
 namespace boost {
-
 namespace detail {
-
 namespace thread {
 
-
 // force_cast will convert anything to anything.
 
 // general case
 template<class Return_Type, class Argument_Type>
 inline Return_Type &force_cast(Argument_Type &rSrc)
-    {   return(*reinterpret_cast<Return_Type *>(&rSrc));    }
+{
+    return(*reinterpret_cast<Return_Type *>(&rSrc));
+}
 
 // specialization for const
 template<class Return_Type, class Argument_Type>
 inline const Return_Type &force_cast(const Argument_Type &rSrc)
-    {   return(*reinterpret_cast<const Return_Type *>(&rSrc));  }
-
+{
+    return(*reinterpret_cast<const Return_Type *>(&rSrc));
+}
 
 } // namespace thread
-
 } // namespace detail
-
 } // namespace boost
 
-
 #endif // BOOST_FORCE_CAST_MJM012402_HPP

include/boost/thread/detail/lock.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,6 +12,8 @@
 #ifndef BOOST_XLOCK_WEK070601_HPP
 #define BOOST_XLOCK_WEK070601_HPP
 
+#include <boost/thread/detail/config.hpp>
+
 #include <boost/utility.hpp>
 #include <boost/thread/exceptions.hpp>
 
@@ -20,188 +22,193 @@ namespace boost {
 class condition;
 struct xtime;
 
-    namespace detail { namespace thread {
+namespace detail { namespace thread {
 
-    template <typename Mutex>
-    class lock_ops : private noncopyable
+template <typename Mutex>
+class lock_ops : private noncopyable
+{
+private:
+    lock_ops() { }
+
+public:
+    typedef typename Mutex::cv_state lock_state;
+
+    static void lock(Mutex& m)
     {
-    private:
-        lock_ops() { }
-
-    public:
-        typedef typename Mutex::cv_state lock_state;
-
-        static void lock(Mutex& m)
-        {
-            m.do_lock();
-        }
-        static bool trylock(Mutex& m)
-        {
-            return m.do_trylock();
-        }
-        static bool timedlock(Mutex& m, const xtime& xt)
-        {
-            return m.do_timedlock(xt);
-        }
-        static void unlock(Mutex& m)
-        {
-            m.do_unlock();
-        }
-        static void lock(Mutex& m, lock_state& state)
-        {
-            m.do_lock(state);
-        }
-        static void unlock(Mutex& m, lock_state& state)
-        {
-            m.do_unlock(state);
-        }
-    };
-
-    template <typename Mutex>
-    class scoped_lock : private noncopyable
+        m.do_lock();
+    }
+    static bool trylock(Mutex& m)
     {
-    public:
-        typedef Mutex mutex_type;
-
-        explicit scoped_lock(Mutex& mx, bool initially_locked=true)
-            : m_mutex(mx), m_locked(false)
-        {
-            if (initially_locked) lock();
-        }
-        ~scoped_lock()
-        {
-            if (m_locked) unlock();
-        }
-
-        void lock()
-        {
-            if (m_locked) throw lock_error();
-            lock_ops<Mutex>::lock(m_mutex);
-            m_locked = true;
-        }
-        void unlock()
-        {
-            if (!m_locked) throw lock_error();
-            lock_ops<Mutex>::unlock(m_mutex);
-            m_locked = false;
-        }
-
-        bool locked() const { return m_locked; }
-        operator const void*() const { return m_locked ? this : 0; }
-
-    private:
-        friend class boost::condition;
-
-        Mutex& m_mutex;
-        bool m_locked;
-    };
-
-    template <typename TryMutex>
-    class scoped_try_lock : private noncopyable
+        return m.do_trylock();
+    }
+    static bool timedlock(Mutex& m, const xtime& xt)
     {
-    public:
-        typedef TryMutex mutex_type;
-
-        explicit scoped_try_lock(TryMutex& mx)
-            : m_mutex(mx), m_locked(false)
-        {
-            try_lock();
-        }
-        scoped_try_lock(TryMutex& mx, bool initially_locked)
-            : m_mutex(mx), m_locked(false)
-        {
-            if (initially_locked) lock();
-        }
-        ~scoped_try_lock()
-        {
-            if (m_locked) unlock();
-        }
-
-        void lock()
-        {
-            if (m_locked) throw lock_error();
-            lock_ops<TryMutex>::lock(m_mutex);
-            m_locked = true;
-        }
-        bool try_lock()
-        {
-            if (m_locked) throw lock_error();
-            return (m_locked = lock_ops<TryMutex>::trylock(m_mutex));
-        }
-        void unlock()
-        {
-            if (!m_locked) throw lock_error();
-            lock_ops<TryMutex>::unlock(m_mutex);
-            m_locked = false;
-        }
-
-        bool locked() const { return m_locked; }
-        operator const void*() const { return m_locked ? this : 0; }
-
-    private:
-        friend class boost::condition;
-
-        TryMutex& m_mutex;
-        bool m_locked;
-    };
-
-    template <typename TimedMutex>
-    class scoped_timed_lock : private noncopyable
+        return m.do_timedlock(xt);
+    }
+    static void unlock(Mutex& m)
     {
-    public:
-        typedef TimedMutex mutex_type;
+        m.do_unlock();
+    }
+    static void lock(Mutex& m, lock_state& state)
+    {
+        m.do_lock(state);
+    }
+    static void unlock(Mutex& m, lock_state& state)
+    {
+        m.do_unlock(state);
+    }
+};
 
-        scoped_timed_lock(TimedMutex& mx, const xtime& xt)
-            : m_mutex(mx), m_locked(false)
-        {
-            timed_lock(xt);
-        }
-        scoped_timed_lock(TimedMutex& mx, bool initially_locked)
-            : m_mutex(mx), m_locked(false)
-        {
-            if (initially_locked) lock();
-        }
-        ~scoped_timed_lock()
-        {
-            if (m_locked) unlock();
-        }
+template <typename Mutex>
+class scoped_lock : private noncopyable
+{
+public:
+    typedef Mutex mutex_type;
 
-        void lock()
-        {
-            if (m_locked) throw lock_error();
-            lock_ops<TimedMutex>::lock(m_mutex);
-            m_locked = true;
-        }
-        bool timed_lock(const xtime& xt)
-        {
-            if (m_locked) throw lock_error();
-            return (m_locked = lock_ops<TimedMutex>::timedlock(m_mutex, xt));
-        }
-        void unlock()
-        {
-            if (!m_locked) throw lock_error();
-            lock_ops<TimedMutex>::unlock(m_mutex);
-            m_locked = false;
-        }
+    explicit scoped_lock(Mutex& mx, bool initially_locked=true)
+        : m_mutex(mx), m_locked(false)
+    {
+        if (initially_locked) lock();
+    }
+    ~scoped_lock()
+    {
+        if (m_locked) unlock();
+    }
 
-        bool locked() const { return m_locked; }
-        operator const void*() const { return m_locked ? this : 0; }
+    void lock()
+    {
+        if (m_locked) throw lock_error();
+        lock_ops<Mutex>::lock(m_mutex);
+        m_locked = true;
+    }
+    void unlock()
+    {
+        if (!m_locked) throw lock_error();
+        lock_ops<Mutex>::unlock(m_mutex);
+        m_locked = false;
+    }
 
-    private:
-        friend class boost::condition;
+    bool locked() const { return m_locked; }
+    operator const void*() const { return m_locked ? this : 0; }
 
-        TimedMutex& m_mutex;
-        bool m_locked;
-    };
+private:
+    friend class boost::condition;
 
-    } // namespace thread
-    } // namespace detail
+    Mutex& m_mutex;
+    bool m_locked;
+};
+
+template <typename TryMutex>
+class scoped_try_lock : private noncopyable
+{
+public:
+    typedef TryMutex mutex_type;
+
+    explicit scoped_try_lock(TryMutex& mx)
+        : m_mutex(mx), m_locked(false)
+    {
+        try_lock();
+    }
+    scoped_try_lock(TryMutex& mx, bool initially_locked)
+        : m_mutex(mx), m_locked(false)
+    {
+        if (initially_locked) lock();
+    }
+    ~scoped_try_lock()
+    {
+        if (m_locked) unlock();
+    }
+
+    void lock()
+    {
+        if (m_locked) throw lock_error();
+        lock_ops<TryMutex>::lock(m_mutex);
+        m_locked = true;
+    }
+    bool try_lock()
+    {
+        if (m_locked) throw lock_error();
+        return (m_locked = lock_ops<TryMutex>::trylock(m_mutex));
+    }
+    void unlock()
+    {
+        if (!m_locked) throw lock_error();
+        lock_ops<TryMutex>::unlock(m_mutex);
+        m_locked = false;
+    }
+
+    bool locked() const { return m_locked; }
+    operator const void*() const { return m_locked ? this : 0; }
+
+private:
+    friend class boost::condition;
+
+    TryMutex& m_mutex;
+    bool m_locked;
+};
+
+template <typename TimedMutex>
+class scoped_timed_lock : private noncopyable
+{
+public:
+    typedef TimedMutex mutex_type;
+
+    scoped_timed_lock(TimedMutex& mx, const xtime& xt)
+        : m_mutex(mx), m_locked(false)
+    {
+        timed_lock(xt);
+    }
+    scoped_timed_lock(TimedMutex& mx, bool initially_locked)
+        : m_mutex(mx), m_locked(false)
+    {
+        if (initially_locked) lock();
+    }
+    ~scoped_timed_lock()
+    {
+        if (m_locked) unlock();
+    }
+
+    void lock()
+    {
+        if (m_locked) throw lock_error();
+        lock_ops<TimedMutex>::lock(m_mutex);
+        m_locked = true;
+    }
+    bool try_lock()
+    {
+        if (m_locked) throw lock_error();
+        return (m_locked = lock_ops<TimedMutex>::trylock(m_mutex));
+    }
+    bool timed_lock(const xtime& xt)
+    {
+        if (m_locked) throw lock_error();
+        return (m_locked = lock_ops<TimedMutex>::timedlock(m_mutex, xt));
+    }
+    void unlock()
+    {
+        if (!m_locked) throw lock_error();
+        lock_ops<TimedMutex>::unlock(m_mutex);
+        m_locked = false;
+    }
+
+    bool locked() const { return m_locked; }
+    operator const void*() const { return m_locked ? this : 0; }
+
+private:
+    friend class boost::condition;
+
+    TimedMutex& m_mutex;
+    bool m_locked;
+};
+
+} // namespace thread
+} // namespace detail
 } // namespace boost
 
+#endif // BOOST_XLOCK_WEK070601_HPP
+
 // Change Log:
 //    8 Feb 01  WEKEMPF Initial version.
 //   22 May 01  WEKEMPF Modified to use xtime for time outs.
-//   30 Jul 01  WEKEMPF Moved lock types into boost::detail::thread. Renamed some types.
-//                      Added locked() methods.
-
-#endif // BOOST_XLOCK_WEK070601_HPP
+//   30 Jul 01  WEKEMPF Moved lock types into boost::detail::thread. Renamed
+//                      some types. Added locked() methods.

include/boost/thread/detail/named.hpp

@@ -0,0 +1,38 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#ifndef BOOST_NAMED_WEK031703_HPP
+#define BOOST_NAMED_WEK031703_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+namespace boost {
+namespace detail {
+
+class named_object
+{
+protected:
+    named_object(const char* name=0);
+    ~named_object();
+
+public:
+    const char* name() const;
+    const char* effective_name() const;
+
+protected:
+    char* m_name;
+    char* m_ename;
+};
+
+} // namespace detail
+} // namespace boost
+
+#endif // BOOST_NAMED_WEK031703_HPP

include/boost/thread/detail/singleton.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // Mac Murrett
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -14,51 +14,50 @@
 #ifndef BOOST_SINGLETON_MJM012402_HPP
 #define BOOST_SINGLETON_MJM012402_HPP
 
+#include <boost/thread/detail/config.hpp>
+
 namespace boost {
-
 namespace detail {
-
 namespace thread {
 
-// class singleton has the same goal as all singletons: create one instance of a
-//  class on demand, then dish it out as requested.
+// class singleton has the same goal as all singletons: create one instance of
+// a class on demand, then dish it out as requested.
 
-template<class T>
-class singleton: private T
+template <class T>
+class singleton : private T
 {
-  private:
+private:
     singleton();
     ~singleton();
 
-  public:
+public:
     static T &instance();
 };
 
 
-template<class T>
+template <class T>
 inline singleton<T>::singleton()
-    {   /* no-op */ }
+{
+    /* no-op */
+}
 
-template<class T>
+template <class T>
 inline singleton<T>::~singleton()
-    {   /* no-op */ }
+{
+    /* no-op */
+}
 
-
-template<class T>
+template <class T>
 /*static*/ T &singleton<T>::instance()
 {
-// function-local static to force this to work correctly at static initialization
-//  time.
+    // function-local static to force this to work correctly at static
+    // initialization time.
     static singleton<T> s_oT;
     return(s_oT);
 }
 
-
 } // namespace thread
-
 } // namespace detail
-
 } // namespace boost
 
-
 #endif // BOOST_SINGLETON_MJM012402_HPP

include/boost/thread/detail/threadmon.hpp

@@ -0,0 +1,35 @@
+// Copyright (C) 2001-2003
+// William E. Kempf
+//
+// 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.
+
+#ifndef BOOST_THREADMON_WEK062504_HPP
+#define BOOST_THREADMON_WEK062504_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+#ifdef BOOST_HAS_WINTHREADS
+
+extern "C" BOOST_THREAD_DECL int at_thread_exit(void (__cdecl * func)(void));
+    //Add a function to the list of thread-exit functions
+
+extern "C" BOOST_THREAD_DECL void on_process_enter(void);
+    //To be called when the process starts, when the dll is loaded, etc.
+    //Called automatically by Boost.Thread when possible
+extern "C" BOOST_THREAD_DECL void on_thread_exit(void);
+    //To be called for each thread when it exits
+    //Must be called in the context of the thread that is exiting
+    //Called automatically by Boost.Thread when possible
+extern "C" BOOST_THREAD_DECL void on_process_exit(void);
+    //To be called when the process exits, when the dll is unloaded, etc.
+    //Called automatically by Boost.Thread when possible
+
+#endif // BOOST_HAS_WINTHREADS
+
+#endif // BOOST_THREADMON_WEK062504_HPP

include/boost/thread/exceptions.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,6 +12,8 @@
 #ifndef BOOST_THREAD_EXCEPTIONS_PDM070801_H
 #define BOOST_THREAD_EXCEPTIONS_PDM070801_H
 
+#include <boost/thread/detail/config.hpp>
+
 //  pdm: Sorry, but this class is used all over the place & I end up
 //       with recursive headers if I don't separate it
 //  wek: Not sure why recursive headers would cause compilation problems
@@ -22,18 +24,77 @@
 
 namespace boost {
 
-class lock_error : public std::runtime_error
+class BOOST_THREAD_DECL thread_exception : public std::exception
+{
+protected:
+    thread_exception();
+    thread_exception(int sys_err_code);
+
+public:
+    ~thread_exception() throw();
+
+    int native_error() const { return m_sys_err; }
+
+    const char* message() const;
+
+private:
+    int m_sys_err;
+};
+
+class BOOST_THREAD_DECL lock_error : public thread_exception
 {
 public:
     lock_error();
+    lock_error(int sys_err_code);
+    ~lock_error() throw();
+
+    virtual const char* what() const throw();
 };
 
-class thread_resource_error : public std::runtime_error
+class BOOST_THREAD_DECL thread_resource_error : public thread_exception
 {
 public:
     thread_resource_error();
+    thread_resource_error(int sys_err_code);
+    ~thread_resource_error() throw();
+
+    virtual const char* what() const throw();
+};
+
+class BOOST_THREAD_DECL unsupported_thread_option : public thread_exception
+{
+public:
+    unsupported_thread_option();
+    unsupported_thread_option(int sys_err_code);
+    ~unsupported_thread_option() throw();
+
+    virtual const char* what() const throw();
+};
+
+class BOOST_THREAD_DECL invalid_thread_argument : public thread_exception
+{
+public:
+    invalid_thread_argument();
+    invalid_thread_argument(int sys_err_code);
+    ~invalid_thread_argument() throw();
+
+    virtual const char* what() const throw();
+};
+
+class BOOST_THREAD_DECL thread_permission_error : public thread_exception
+{
+public:
+    thread_permission_error();
+    thread_permission_error(int sys_err_code);
+    ~thread_permission_error() throw();
+
+    virtual const char* what() const throw();
 };
 
 } // namespace boost
 
 #endif // BOOST_THREAD_CONFIG_PDM070801_H
+
+// Change log:
+//    3 Jan 03  WEKEMPF Modified for DLL implementation.
+

include/boost/thread/mutex.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,13 +12,11 @@
 #ifndef BOOST_MUTEX_WEK070601_HPP
 #define BOOST_MUTEX_WEK070601_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
 #include <boost/utility.hpp>
 #include <boost/thread/detail/lock.hpp>
+#include <boost/thread/detail/named.hpp>
 
 #if defined(BOOST_HAS_PTHREADS)
 #   include <pthread.h>
@@ -32,14 +30,16 @@ namespace boost {
 
 struct xtime;
 
-class mutex : private noncopyable
+class BOOST_THREAD_DECL mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<mutex>;
 
     typedef detail::thread::scoped_lock<mutex> scoped_lock;
 
-    mutex();
+    mutex(const char* name=0);
     ~mutex();
 
 private:
@@ -62,6 +62,7 @@ private:
 
 #if defined(BOOST_HAS_WINTHREADS)
     void* m_mutex;
+    bool m_critical_section;
 #elif defined(BOOST_HAS_PTHREADS)
     pthread_mutex_t m_mutex;
 #elif defined(BOOST_HAS_MPTASKS)
@@ -70,7 +71,9 @@ private:
 #endif
 };
 
-class try_mutex : private noncopyable
+class BOOST_THREAD_DECL try_mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<try_mutex>;
@@ -78,7 +81,7 @@ public:
     typedef detail::thread::scoped_lock<try_mutex> scoped_lock;
     typedef detail::thread::scoped_try_lock<try_mutex> scoped_try_lock;
 
-    try_mutex();
+    try_mutex(const char* name=0);
     ~try_mutex();
 
 private:
@@ -102,6 +105,7 @@ private:
 
 #if defined(BOOST_HAS_WINTHREADS)
     void* m_mutex;
+    bool m_critical_section;
 #elif defined(BOOST_HAS_PTHREADS)
     pthread_mutex_t m_mutex;
 #elif defined(BOOST_HAS_MPTASKS)
@@ -110,7 +114,9 @@ private:
 #endif
 };
 
-class timed_mutex : private noncopyable
+class BOOST_THREAD_DECL timed_mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<timed_mutex>;
@@ -119,7 +125,7 @@ public:
     typedef detail::thread::scoped_try_lock<timed_mutex> scoped_try_lock;
     typedef detail::thread::scoped_timed_lock<timed_mutex> scoped_timed_lock;
 
-    timed_mutex();
+    timed_mutex(const char* name=0);
     ~timed_mutex();
 
 private:
@@ -160,5 +166,6 @@ private:
 //    8 Feb 01  WEKEMPF Initial version.
 //   22 May 01  WEKEMPF Modified to use xtime for time outs.  Factored out
 //                      to three classes, mutex, try_mutex and timed_mutex.
+//    3 Jan 03  WEKEMPF Modified for DLL implementation.
 
 #endif // BOOST_MUTEX_WEK070601_HPP

include/boost/thread/once.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,10 +12,7 @@
 #ifndef BOOST_ONCE_WEK080101_HPP
 #define BOOST_ONCE_WEK080101_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
 #if defined(BOOST_HAS_PTHREADS)
 #   include <pthread.h>
@@ -30,12 +27,12 @@ typedef pthread_once_t once_flag;
 
 #elif (defined(BOOST_HAS_WINTHREADS) || defined(BOOST_HAS_MPTASKS))
 
-typedef bool once_flag;
-#define BOOST_ONCE_INIT false
+typedef long once_flag;
+#define BOOST_ONCE_INIT 0
 
 #endif
 
-void call_once(void (*func)(), once_flag& flag);
+void BOOST_THREAD_DECL call_once(void (*func)(), once_flag& flag);
 
 } // namespace boost
 

include/boost/thread/read_write_mutex.hpp

@@ -0,0 +1,271 @@
+// Copyright (C)  2002-2003
+// David Moore, William E. Kempf
+//
+// 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.  David Moore makes no representations
+// about the suitability of this software for any purpose.
+// It is provided "as is" without express or implied warranty.
+
+// A Boost::threads implementation of a synchronization
+//   primitive which can allow multiple readers or a single
+//   writer to have access to a shared resource.
+
+#ifndef BOOST_READ_WRITE_MUTEX_JDM030602_HPP
+#define BOOST_READ_WRITE_MUTEX_JDM030602_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+#include <boost/utility.hpp>
+
+#include <boost/thread/mutex.hpp>
+#include <boost/thread/detail/lock.hpp>
+#include <boost/thread/detail/read_write_lock.hpp>
+#include <boost/thread/condition.hpp>
+
+namespace boost {
+
+namespace read_write_scheduling_policy {
+    enum read_write_scheduling_policy_enum
+    {
+        writer_priority,               //Prefer writers; can starve readers
+        reader_priority,               //Prefer readers; can starve writers
+        alternating_many_reads,        //Alternate readers and writers; before a writer, release all queued readers 
+        alternating_single_read        //Alternate readers and writers; before a writer, release only on queued reader
+    };
+} // namespace read_write_scheduling_policy
+
+namespace detail {
+
+namespace thread {
+
+// Shared implementation construct for explicit Scheduling Policies
+// This implementation is susceptible to self-deadlock, though....
+template<typename Mutex>
+struct read_write_mutex_impl
+{
+    typedef Mutex mutex_type;
+    typedef detail::thread::scoped_lock<Mutex> scoped_lock;
+    typedef detail::thread::scoped_try_lock<Mutex> scoped_try_lock;
+    typedef detail::thread::scoped_timed_lock<Mutex> scoped_timed_lock;
+
+    read_write_mutex_impl(read_write_scheduling_policy::read_write_scheduling_policy_enum sp)
+        : m_num_waiting_writers(0),
+          m_num_waiting_readers(0),
+          m_num_readers_to_wake(0),
+          m_state_waiting_promotion(false),
+          m_state(0),
+          m_sp(sp),
+          m_readers_next(true) { }
+
+    Mutex m_prot;
+    boost::condition m_waiting_writers;
+    boost::condition m_waiting_readers;
+    int m_num_waiting_writers;
+    int m_num_waiting_readers;
+    int m_num_readers_to_wake;
+    boost::condition m_waiting_promotion;
+    bool m_state_waiting_promotion;
+    int m_state;    // -1 = excl locked
+                    // 0 = unlocked
+                    // 1-> INT_MAX - shared locked
+    const read_write_scheduling_policy::read_write_scheduling_policy_enum m_sp;
+    bool m_readers_next;
+
+    void do_read_lock();
+    void do_write_lock();
+    void do_write_unlock();
+    void do_read_unlock();
+    bool do_try_write_lock();
+    bool do_try_read_lock();
+    bool do_timed_write_lock(const xtime &xt);
+    bool do_timed_read_lock(const xtime &xt);
+
+    void do_demote_to_read_lock();
+    bool do_try_demote_to_read_lock();
+    bool do_timed_demote_to_read_lock(const xtime &xt);
+
+    void do_promote_to_write_lock();
+    bool do_try_promote_to_write_lock();
+    bool do_timed_promote_to_write_lock(const xtime &xt);
+
+    bool locked();
+    read_write_lock_state::read_write_lock_state_enum state();
+
+private:
+
+    void do_unlock_scheduling_impl();
+    void do_demote_scheduling_impl();
+    void do_scheduling_impl();
+    bool do_demote_to_read_lock_impl();
+};
+
+} // namespace detail
+
+} // namespace thread
+
+class BOOST_THREAD_DECL read_write_mutex : private noncopyable
+{
+public:
+
+    read_write_mutex(read_write_scheduling_policy::read_write_scheduling_policy_enum sp) : m_impl(sp) { }
+    ~read_write_mutex() { }
+
+    read_write_scheduling_policy::read_write_scheduling_policy_enum policy() const { return m_impl.m_sp; }
+
+    friend class detail::thread::read_write_lock_ops<read_write_mutex>;
+
+    typedef detail::thread::scoped_read_write_lock<
+        read_write_mutex> scoped_read_write_lock;
+
+    typedef detail::thread::scoped_read_lock<
+        read_write_mutex> scoped_read_lock;
+
+    typedef detail::thread::scoped_write_lock<
+        read_write_mutex> scoped_write_lock;
+
+private:
+
+    // Operations that will eventually be done only
+    //   via lock types
+    void do_write_lock();
+    void do_read_lock();
+    void do_write_unlock();
+    void do_read_unlock();
+
+    void do_demote_to_read_lock();
+
+    void do_promote_to_write_lock();
+
+    bool locked();
+    read_write_lock_state::read_write_lock_state_enum state();
+
+    detail::thread::read_write_mutex_impl<mutex> m_impl; 
+};
+
+class BOOST_THREAD_DECL try_read_write_mutex : private noncopyable
+{
+public:
+
+    try_read_write_mutex(read_write_scheduling_policy::read_write_scheduling_policy_enum sp) : m_impl(sp) { }
+    ~try_read_write_mutex() { }
+
+    read_write_scheduling_policy::read_write_scheduling_policy_enum policy() const { return m_impl.m_sp; }
+
+    friend class detail::thread::read_write_lock_ops<try_read_write_mutex>;
+
+    typedef detail::thread::scoped_read_write_lock<
+        try_read_write_mutex> scoped_read_write_lock;
+    typedef detail::thread::scoped_try_read_write_lock<
+        try_read_write_mutex> scoped_try_read_write_lock;
+
+    typedef detail::thread::scoped_read_lock<
+        try_read_write_mutex> scoped_read_lock;
+    typedef detail::thread::scoped_try_read_lock<
+        try_read_write_mutex> scoped_try_read_lock;
+
+    typedef detail::thread::scoped_write_lock<
+        try_read_write_mutex> scoped_write_lock;
+    typedef detail::thread::scoped_try_write_lock<
+        try_read_write_mutex> scoped_try_write_lock;
+
+private:
+
+    // Operations that will eventually be done only
+    //   via lock types
+    void do_write_lock();
+    void do_read_lock();
+    void do_write_unlock();
+    void do_read_unlock();
+    bool do_try_write_lock();
+    bool do_try_read_lock();
+
+
+    void do_demote_to_read_lock();
+    bool do_try_demote_to_read_lock();
+
+    void do_promote_to_write_lock();
+    bool do_try_promote_to_write_lock();
+
+    bool locked();
+    read_write_lock_state::read_write_lock_state_enum state();
+
+    detail::thread::read_write_mutex_impl<try_mutex> m_impl; 
+};
+
+class BOOST_THREAD_DECL timed_read_write_mutex : private noncopyable
+{
+public:
+
+    timed_read_write_mutex(read_write_scheduling_policy::read_write_scheduling_policy_enum sp) : m_impl(sp) { }
+    ~timed_read_write_mutex() { }
+
+    read_write_scheduling_policy::read_write_scheduling_policy_enum policy() const { return m_impl.m_sp; }
+
+    friend class detail::thread::read_write_lock_ops<timed_read_write_mutex>;
+
+    typedef detail::thread::scoped_read_write_lock<
+        timed_read_write_mutex> scoped_read_write_lock;
+    typedef detail::thread::scoped_try_read_write_lock<
+        timed_read_write_mutex> scoped_try_read_write_lock;
+    typedef detail::thread::scoped_timed_read_write_lock<
+        timed_read_write_mutex> scoped_timed_read_write_lock;
+
+    typedef detail::thread::scoped_read_lock<
+        timed_read_write_mutex> scoped_read_lock;
+    typedef detail::thread::scoped_try_read_lock<
+        timed_read_write_mutex> scoped_try_read_lock;
+    typedef detail::thread::scoped_timed_read_lock<
+        timed_read_write_mutex> scoped_timed_read_lock;
+
+    typedef detail::thread::scoped_write_lock<
+        timed_read_write_mutex> scoped_write_lock;
+    typedef detail::thread::scoped_try_write_lock<
+        timed_read_write_mutex> scoped_try_write_lock;
+    typedef detail::thread::scoped_timed_write_lock<
+        timed_read_write_mutex> scoped_timed_write_lock;
+
+private:
+
+    // Operations that will eventually be done only
+    //   via lock types
+    void do_write_lock();
+    void do_read_lock();
+    void do_write_unlock();
+    void do_read_unlock();
+    bool do_try_write_lock();
+    bool do_try_read_lock();
+    bool do_timed_write_lock(const xtime &xt);
+    bool do_timed_read_lock(const xtime &xt);
+    
+    void do_demote_to_read_lock();
+    bool do_try_demote_to_read_lock();
+    bool do_timed_demote_to_read_lock(const xtime &xt);
+
+    void do_promote_to_write_lock();
+    bool do_try_promote_to_write_lock();
+    bool do_timed_promote_to_write_lock(const xtime &xt);
+
+    bool locked();
+    read_write_lock_state::read_write_lock_state_enum state();
+
+    detail::thread::read_write_mutex_impl<timed_mutex> m_impl; 
+};
+
+}    // namespace boost
+
+#endif
+
+// Change Log:
+//  10 Mar 02 
+//      Original version.
+//   4 May 04 GlassfordM
+//      Implement lock promotion and demotion.
+//      Add locked() and state() member functions for debugging
+//         (should these be made public?).
+//      Rename to improve consistency and eliminate abbreviations:
+//          Use "read" and "write" instead of "shared" and "exclusive".
+//          Change "rd" to "read", "wr" to "write", "rw" to "read_write".
+//      Add mutex_type typdef.

include/boost/thread/recursive_mutex.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,17 +12,17 @@
 #ifndef BOOST_RECURSIVE_MUTEX_WEK070601_HPP
 #define BOOST_RECURSIVE_MUTEX_WEK070601_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
 #include <boost/utility.hpp>
 #include <boost/thread/detail/lock.hpp>
+#include <boost/thread/detail/named.hpp>
 
 #if defined(BOOST_HAS_PTHREADS)
 #   include <pthread.h>
-#elif defined(BOOST_HAS_MPTASKS)
+#endif
+
+#if defined(BOOST_HAS_MPTASKS)
 #   include "scoped_critical_region.hpp"
 #endif
 
@@ -30,14 +30,16 @@ namespace boost {
 
 struct xtime;
 
-class recursive_mutex : private noncopyable
+class BOOST_THREAD_DECL recursive_mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<recursive_mutex>;
 
     typedef detail::thread::scoped_lock<recursive_mutex> scoped_lock;
 
-    recursive_mutex();
+    recursive_mutex(const char* name=0);
     ~recursive_mutex();
 
 private:
@@ -57,6 +59,7 @@ private:
 
 #if defined(BOOST_HAS_WINTHREADS)
     void* m_mutex;
+    bool m_critical_section;
     unsigned long m_count;
 #elif defined(BOOST_HAS_PTHREADS)
     pthread_mutex_t m_mutex;
@@ -73,15 +76,18 @@ private:
 #endif
 };
 
-class recursive_try_mutex : private noncopyable
+class BOOST_THREAD_DECL recursive_try_mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<recursive_try_mutex>;
 
     typedef detail::thread::scoped_lock<recursive_try_mutex> scoped_lock;
-    typedef detail::thread::scoped_try_lock<recursive_try_mutex> scoped_try_lock;
+    typedef detail::thread::scoped_try_lock<
+        recursive_try_mutex> scoped_try_lock;
 
-    recursive_try_mutex();
+    recursive_try_mutex(const char* name=0);
     ~recursive_try_mutex();
 
 private:
@@ -102,6 +108,7 @@ private:
 
 #if defined(BOOST_HAS_WINTHREADS)
     void* m_mutex;
+    bool m_critical_section;
     unsigned long m_count;
 #elif defined(BOOST_HAS_PTHREADS)
     pthread_mutex_t m_mutex;
@@ -118,16 +125,20 @@ private:
 #endif
 };
 
-class recursive_timed_mutex : private noncopyable
+class BOOST_THREAD_DECL recursive_timed_mutex
+    : private noncopyable
+    , public boost::detail::named_object
 {
 public:
     friend class detail::thread::lock_ops<recursive_timed_mutex>;
 
     typedef detail::thread::scoped_lock<recursive_timed_mutex> scoped_lock;
-    typedef detail::thread::scoped_try_lock<recursive_timed_mutex> scoped_try_lock;
-    typedef detail::thread::scoped_timed_lock<recursive_timed_mutex> scoped_timed_lock;
+    typedef detail::thread::scoped_try_lock<
+        recursive_timed_mutex> scoped_try_lock;
+    typedef detail::thread::scoped_timed_lock<
+        recursive_timed_mutex> scoped_timed_lock;
 
-    recursive_timed_mutex();
+    recursive_timed_mutex(const char* name=0);
     ~recursive_timed_mutex();
 
 private:
@@ -165,10 +176,11 @@ private:
 
 } // namespace boost
 
+#endif // BOOST_RECURSIVE_MUTEX_WEK070601_HPP
+
 // Change Log:
 //    8 Feb 01  WEKEMPF Initial version.
 //    1 Jun 01  WEKEMPF Modified to use xtime for time outs.  Factored out
 //                      to three classes, mutex, try_mutex and timed_mutex.
 //   11 Jun 01  WEKEMPF Modified to use PTHREAD_MUTEX_RECURSIVE if available.
-
-#endif // BOOST_RECURSIVE_MUTEX_WEK070601_HPP
+//    3 Jan 03  WEKEMPF Modified for DLL implementation.

include/boost/thread/shared_memory.hpp

@@ -0,0 +1,58 @@
+// Copyright (C) 2002-2003
+// William E. Kempf, David Moore
+//
+// 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.
+
+#ifndef BOOST_MUTEX_JDM062402_HPP
+#define BOOST_MUTEX_JDM062402_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+#include <boost/utility.hpp>
+#include <boost/function.hpp>
+
+#include <boost/thread/exceptions.hpp>
+#include <boost/thread/detail/named.hpp>
+
+#include <string>
+
+namespace boost {
+
+class shared_memory : public boost::detail::named_object
+{
+public:
+    enum {
+        write=0x1,
+        create=0x2,
+        exclusive=0x4,
+    };
+
+    shared_memory(const char *name, std::size_t len, int flags);
+    shared_memory(const char *name, std::size_t len, int flags,
+        const boost::function1<void,void *>& initfunc);
+    ~shared_memory();
+
+    void* get() const { return m_ptr; }
+
+private:
+    void init(std::size_t len, int flags,
+        const boost::function1<void, void*>* initfunc);
+
+    void *m_ptr;        // Pointer to shared memory block
+#if defined(BOOST_HAS_WINTHREADS)
+    void* m_hmap;
+#elif defined(BOOST_HAS_PTHREADS)
+    std::size_t m_len;
+    int m_hmap;
+#endif
+};
+
+}  // namespace boost
+
+#endif

include/boost/thread/thread.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,14 +12,11 @@
 #ifndef BOOST_THREAD_WEK070601_HPP
 #define BOOST_THREAD_WEK070601_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
-#include <boost/utility.hpp>
 #include <boost/function.hpp>
 #include <boost/thread/mutex.hpp>
+#include <iostream>
 #include <list>
 #include <memory>
 
@@ -34,56 +31,163 @@ namespace boost {
 
 struct xtime;
 
-class thread : private noncopyable
+class BOOST_THREAD_DECL thread_cancel
 {
 public:
+    thread_cancel();
+    ~thread_cancel();
+};
+
+class BOOST_THREAD_DECL cancellation_guard
+{
+public:
+    cancellation_guard();
+    ~cancellation_guard();
+
+private:
+    void* m_handle;
+};
+
+#if defined(BOOST_HAS_WINTHREADS)
+
+struct sched_param
+{
+    int priority;
+};
+
+enum { sched_fifo, sched_round_robin, sched_other };
+enum { scope_process, scope_system };
+
+#elif defined(BOOST_HAS_PTHREADS)
+
+using ::sched_param;
+
+enum
+{
+    sched_fifo = SCHED_FIFO,
+    sched_round_robin = SCHED_RR,
+    sched_other = SCHED_OTHER
+};
+
+enum
+{
+    scope_process = PTHREAD_SCOPE_PROCESS,
+    scope_system = PTHREAD_SCOPE_SYSTEM
+};
+
+#endif
+
+class BOOST_THREAD_DECL thread
+{
+public:
+    class BOOST_THREAD_DECL attributes
+    {
+    public:
+        attributes();
+        ~attributes();
+
+        attributes& set_stack_size(size_t size);
+        size_t get_stack_size() const;
+
+        attributes& set_stack_address(void* addr);
+        void* get_stack_address() const;
+
+        attributes& inherit_scheduling(bool inherit);
+        bool inherit_scheduling() const;
+        attributes& set_schedule(int policy, const sched_param& param);
+        void get_schedule(int& policy, sched_param& param);
+        attributes& scope(int scope);
+        int scope() const;
+
+    private:
+        friend class thread;
+
+#if defined(BOOST_HAS_WINTHREADS)
+        size_t m_stacksize;
+        bool m_schedinherit;
+        sched_param m_schedparam;
+#elif defined(BOOST_HAS_PTHREADS)
+        pthread_attr_t m_attr;
+#endif
+    };
+
     thread();
-    explicit thread(const function0<void>& threadfunc);
+    explicit thread(const function0<void>& threadfunc,
+        const attributes& attr=attributes());
+    thread(const thread& other);
     ~thread();
 
+    thread& operator=(const thread& other);
+
     bool operator==(const thread& other) const;
     bool operator!=(const thread& other) const;
+    bool operator<(const thread& other) const;
 
     void join();
+    bool timed_join(const xtime& xt);
+    void cancel();
+    bool cancelled() const;
 
+    void set_scheduling_parameter(int policy, const sched_param& param);
+    void get_scheduling_parameter(int& policy, sched_param& param) const;
+
+    static int max_priority(int policy);
+    static int min_priority(int policy);
+
+    static void test_cancel();
     static void sleep(const xtime& xt);
     static void yield();
 
-private:
+    static const int stack_min;
+
 #if defined(BOOST_HAS_WINTHREADS)
-    void* m_thread;
-    unsigned int m_id;
-#elif defined(BOOST_HAS_PTHREADS)
-private:
-    pthread_t m_thread;
-#elif defined(BOOST_HAS_MPTASKS)
-    MPQueueID m_pJoinQueueID;
-    MPTaskID m_pTaskID;
+    typedef unsigned int id_type;
+#else
+    typedef const void* id_type;
 #endif
-    bool m_joinable;
+
+    id_type id() const;
+
+private:
+    void* m_handle;
 };
 
-class thread_group : private noncopyable
+template <typename charT, typename Traits>
+std::basic_ostream<charT, Traits>& operator<<(
+    std::basic_ostream<charT, Traits>& os, const thread& thrd)
+{
+    if (!os.good()) return os;
+
+    typename std::basic_ostream<charT, Traits>::sentry opfx(os);
+
+    if (opfx)
+        os << thrd.id();
+
+    return os;
+}
+
+class BOOST_THREAD_DECL thread_group : private noncopyable
 {
 public:
     thread_group();
     ~thread_group();
 
-    thread* create_thread(const function0<void>& threadfunc);
-    void add_thread(thread* thrd);
-    void remove_thread(thread* thrd);
+    thread create_thread(const function0<void>& threadfunc);
+    void add_thread(thread thrd);
+    void remove_thread(thread thrd);
+//  thread* thread_group::find(thread& thrd);
     void join_all();
 
 private:
-    std::list<thread*> m_threads;
+    std::list<thread> m_threads;
     mutex m_mutex;
 };
 
 } // namespace boost
 
+#endif // BOOST_THREAD_WEK070601_HPP
+
 // Change Log:
 //    8 Feb 01  WEKEMPF Initial version.
 //    1 Jun 01  WEKEMPF Added boost::thread initial implementation.
 //    3 Jul 01  WEKEMPF Redesigned boost::thread to be noncopyable.
-
-#endif // BOOST_THREAD_WEK070601_HPP

include/boost/thread/thread_pool.hpp

@@ -0,0 +1,44 @@
+// Copyright (C)  2002-2003
+// David Moore, William E. Kempf
+//
+// 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.
+
+// Derived loosely from work queue manager in "Programming POSIX Threads"
+//   by David Butenhof.
+
+#ifndef BOOST_THREAD_POOL_JDM031802_HPP
+#define BOOST_THREAD_POOL_JDM031802_HPP
+
+#include <boost/thread/detail/config.hpp>
+
+#include <boost/function.hpp>
+#include <boost/limits.hpp>
+
+namespace boost {
+
+class BOOST_THREAD_DECL thread_pool
+{
+public:
+    thread_pool(int max_threads=std::numeric_limits<int>::max(),
+        int min_threads=0, int timeout_secs=5, int timeout_nsecs=0);
+    ~thread_pool();
+
+    void add(const boost::function0<void> &job);
+    void join();
+    void cancel();
+    void detach();
+
+private:
+    class impl;
+    impl* m_pimpl;
+};
+
+}   // namespace boost
+
+#endif

include/boost/thread/tss.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,12 +12,11 @@
 #ifndef BOOST_TSS_WEK070601_HPP
 #define BOOST_TSS_WEK070601_HPP
 
-#include <boost/config.hpp>
-#ifndef BOOST_HAS_THREADS
-#   error   Thread support is unavailable!
-#endif
+#include <boost/thread/detail/config.hpp>
 
 #include <boost/utility.hpp>
+#include <boost/function.hpp>
+#include <boost/thread/exceptions.hpp>
 
 #if defined(BOOST_HAS_PTHREADS)
 #   include <pthread.h>
@@ -27,55 +26,96 @@
 
 namespace boost {
 
-    namespace detail {
-        class tss : private noncopyable
+namespace detail {
+
+class BOOST_THREAD_DECL tss : private noncopyable
+{
+public:
+    tss(boost::function1<void, void*>* pcleanup) {
+        if (pcleanup == 0) throw boost::thread_resource_error();
+        try
         {
-        public:
-            tss(void (*cleanup)(void*)=0);
-            ~tss();
-
-            void* get() const;
-            bool set(void* value);
-
-        private:
-        #if defined(BOOST_HAS_WINTHREADS)
-            unsigned long m_key;
-            void (*m_cleanup)(void*);
-        #elif defined(BOOST_HAS_PTHREADS)
-            pthread_key_t m_key;
-        #elif defined(BOOST_HAS_MPTASKS)
-            TaskStorageIndex m_key;
-            void (*m_cleanup)(void*);
-        #endif
-        };
-
-    #if defined(BOOST_HAS_MPTASKS)
-        void thread_cleanup();
-    #endif
+            init(pcleanup);
+        }
+        catch (...)
+        {
+            delete pcleanup;
+            throw boost::thread_resource_error();
+        }
     }
 
+    void* get() const;
+    void set(void* value);
+    void cleanup(void* p);
+
+private:
+    unsigned int m_slot; //This is a "pseudo-slot", not a native slot
+
+    void init(boost::function1<void, void*>* pcleanup);
+};
+
+#if defined(BOOST_HAS_MPTASKS)
+void thread_cleanup();
+#endif
+
+template <typename T>
+struct tss_adapter
+{
+    template <typename F>
+    tss_adapter(const F& cleanup) : m_cleanup(cleanup) { }
+    void operator()(void* p) { m_cleanup(static_cast<T*>(p)); }
+    boost::function1<void, T*> m_cleanup;
+};
+
+} // namespace detail
+
 template <typename T>
 class thread_specific_ptr : private noncopyable
 {
 public:
-    thread_specific_ptr() : m_tss(&thread_specific_ptr<T>::cleanup) { }
+    thread_specific_ptr()
+        : m_tss(new boost::function1<void, void*>(
+                    boost::detail::tss_adapter<T>(
+                        &thread_specific_ptr<T>::cleanup)))
+    {
+    }
+    thread_specific_ptr(void (*clean)(T*))
+        : m_tss(new boost::function1<void, void*>(
+                    boost::detail::tss_adapter<T>(clean)))
+    {
+    }
+    ~thread_specific_ptr() { reset(); }
 
     T* get() const { return static_cast<T*>(m_tss.get()); }
     T* operator->() const { return get(); }
     T& operator*() const { return *get(); }
-    T* release() { T* temp = get(); m_tss.set(0); return temp; }
-    void reset(T* p=0) { T* cur = get(); if (cur == p) return; delete cur; m_tss.set(p); }
+    T* release() { T* temp = get(); if (temp) m_tss.set(0); return temp; }
+    void reset(T* p=0)
+    {
+        T* cur = get();
+        if (cur == p) return;
+        m_tss.set(p);
+        if (cur) m_tss.cleanup(cur);
+    }
 
 private:
-    static void cleanup(void* p) { delete static_cast<T*>(p); }
-
-    mutable detail::tss m_tss;
+    static void cleanup(T* p) { delete p; }
+    detail::tss m_tss;
 };
 
 } // namespace boost
 
+#endif //BOOST_TSS_WEK070601_HPP
+
 // Change Log:
-//   6 Jun 01  WEKEMPF Initial version.
-
-#endif // BOOST_TSS_WEK070601_HPP
-
+//   6 Jun 01  
+//      WEKEMPF Initial version.
+//  30 May 02  WEKEMPF 
+//      Added interface to set specific cleanup handlers.
+//      Removed TLS slot limits from most implementations.
+//  22 Mar 04 GlassfordM for WEKEMPF
+//      Fixed: thread_specific_ptr::reset() doesn't check error returned
+//          by tss::set(); tss::set() now throws if it fails.
+//      Fixed: calling thread_specific_ptr::reset() or 
+//          thread_specific_ptr::release() causes double-delete: once on
+//          reset()/release() and once on ~thread_specific_ptr().

include/boost/thread/xtime.hpp

@@ -1,4 +1,4 @@
-// Copyright (C) 2001
+// Copyright (C) 2001-2003
 // William E. Kempf
 //
 // Permission to use, copy, modify, distribute and sell this software
@@ -12,21 +12,22 @@
 #ifndef BOOST_XTIME_WEK070601_HPP
 #define BOOST_XTIME_WEK070601_HPP
 
+#include <boost/thread/detail/config.hpp>
+
 #include <boost/cstdint.hpp>
-#include <boost/config.hpp>
 
 namespace boost {
 
-enum
+enum xtime_clock_types
 {
-    TIME_UTC=1,
-    TIME_TAI,
-    TIME_MONOTONIC,
-    TIME_PROCESS,
-    TIME_THREAD,
-    TIME_LOCAL,
-    TIME_SYNC,
-    TIME_RESOLUTION
+    TIME_UTC=1
+//    TIME_TAI,
+//    TIME_MONOTONIC,
+//    TIME_PROCESS,
+//    TIME_THREAD,
+//    TIME_LOCAL,
+//    TIME_SYNC,
+//    TIME_RESOLUTION
 };
 
 struct xtime
@@ -39,7 +40,14 @@ struct xtime
     int_fast32_t nsec;
 };
 
-int xtime_get(struct xtime* xtp, int clock_type);
+int BOOST_THREAD_DECL xtime_get(struct xtime* xtp, int clock_type);
+inline int xtime_cmp(const xtime& xt1, const xtime& xt2)
+{
+    int res = (int)(xt1.sec - xt2.sec);
+    if (res == 0)
+        res = (int)(xt1.nsec - xt2.nsec);
+    return res;
+}
 
 } // namespace boost