diff --git a/build/Jamfile b/build/Jamfile
index e0250558..7ef2bc88 100644
--- a/build/Jamfile
+++ b/build/Jamfile
@@ -31,17 +31,21 @@ subproject libs/thread/build ;
 SEARCH on <module@>threads.jam = $(SUBDIR) ;
 include <module@>threads.jam ;
 
+template thread_libs
+    ## sources ##
+    : <template>thread_base
+    ## requirements ##
+    :
+    ## default build ##
+    : debug release <runtime-link>static/dynamic
+;
+
 #######################
 # Conditionally declare the Boost.Threads dynamic link library boost_threadmon.
 
 if $(NT) && ! $(PTW32)
 {
-    dll boost_threadmon
-        : ../src/threadmon.cpp
-        : <include>$(BOOST_ROOT)
-          <threading>multi
-        : debug release <runtime-link>static/dynamic
-    ;
+    dll boost_threadmon : <template>thread_libs ../src/threadmon.cpp ;
 }
 
 #######################
@@ -51,13 +55,7 @@ if $(NT) && ! $(PTW32)
 CPP_SOURCES =
     condition mutex recursive_mutex thread tss xtime once exceptions thread_pool barrier rw_mutex ;
 
-lib boost_thread
-    : ../src/$(CPP_SOURCES).cpp
-    : <include>$(BOOST_ROOT)
-      <threading>multi
-      $(pthreads-win32)
-    : debug release <runtime-link>static/dynamic
-;
+lib boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp ;
 
 #######################
 # Stage the generated targets.
diff --git a/build/threads.jam b/build/threads.jam
index f747e9b7..37f4caa3 100644
--- a/build/threads.jam
+++ b/build/threads.jam
@@ -9,15 +9,24 @@ if $(NT)
     {
         local install-path = $(PTW32[1]) ;
         local lib = $(PTW32[2]) ;
-		pthreads-win32 =
-		      <define>BOOST_HAS_PTHREADS
+        pthreads-win32 =
+              <define>BOOST_HAS_PTHREADS
               <define>PtW32NoCatchWarn
               <include>$(install-path)/pre-built/include
               <library-file>$(install-path)/pre-built/lib/$(lib)
-		;
+        ;
     }
     else
     {
         threadmon = <dll>../build/boost_threadmon ;
     }
 }
+
+template thread_base
+    ## sources ##
+    :
+    ## requirements ##
+    : <sysinclude>$(BOOST_ROOT) <threading>multi $(pthreads-win32)
+    ## default build ##
+    :
+;
diff --git a/build/threads.mcp b/build/threads.mcp
index 70ed21bf..ba3aaeff 100644
Binary files a/build/threads.mcp and b/build/threads.mcp differ
diff --git a/doc/acknowledgments.html b/doc/acknowledgments.html
index 6b3393ff..7b5d1da2 100644
--- a/doc/acknowledgments.html
+++ b/doc/acknowledgments.html
@@ -7,20 +7,20 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Acknowledgments</h2>
     </td>
   </tr>
 </table>
 <hr>
-<p><a href="../../../people/william_kempf.htm">William E. Kempf</a> was the architect, 
+<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 
+<p>Mac OS Carbon implementation written by <a href="../../../people/mac_murrett.htm">Mac
   Murrett</a>.</p>
 <p><a href="mailto:jdmoore99@comcast.net">Dave Moore</a> provided initial submissions 
   and further comments on the <code>barrier</code>, <code>thread_pool</code>, 
@@ -33,41 +33,41 @@
   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).</p>
-<p>The documentation was written by William E. Kempf. Beman Dawes provided additional 
+<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 
+<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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/bibliography.html b/doc/bibliography.html
index ccac70ed..ebbb1287 100644
--- a/doc/bibliography.html
+++ b/doc/bibliography.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Bibliography</h2>
     </td>
@@ -19,147 +19,147 @@
 </table>
 <hr>
 <table summary="Bibliography" border="0" cellpadding="5" width="777">
-  <tr> 
+  <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. 
+    <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, 
+                    "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> 
+  <tr>
     <td width="102" valign="top" align="left"><b>[<a name=
                 "Boost">Boost</a>]</b></td>
     <td width="645"> The <cite>Boost</cite> worldwide 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 
+                    "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> 
+  <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>, 
+    <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 
+                    "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> 
+  <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 
+    <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"> 
+                    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 multithreaded programming, not just 
+      <p>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.</p>
     </td>
   </tr>
-  <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 
+    <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 
-        multithreading patterns. This is one of the most often referenced papers 
+      <p>Hoare and Brinch Hansen&#39;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.</p>
     </td>
   </tr>
-  <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"> 
+    <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 
+      <p>This is the official C++ Standards document. Available from the ANSI
         (American National Standards Institute) Electronic Standards Store.</p>
     </td>
   </tr>
-  <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. 
+    <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 
+                    "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> 
+  <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, 
+    <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 
+      <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> 
+  <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 
+    <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">
         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 
+      <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> 
+  <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>, 
+    <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 
+                    "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 
+<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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> and 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> and
   Beman Dawes 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. 
+<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>
diff --git a/doc/condition.html b/doc/condition.html
index c039998e..e427ea3d 100644
--- a/doc/condition.html
+++ b/doc/condition.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/condition.hpp">boost/thread/condition.hpp</a>&gt;</h2>
     </td>
@@ -19,16 +19,16 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-condition">Class <code>condition</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-condition-synopsis">Class <code>condition</code> synopsis</a></dt>
-      <dt><a href="#class-condition-ctors">Class <code>condition</code> constructors 
+      <dt><a href="#class-condition-ctors">Class <code>condition</code> constructors
         and destructor</a></dt>
-      <dt><a href="#class-condition-modifiers">Class <code>condition</code> modifier 
+      <dt><a href="#class-condition-modifiers">Class <code>condition</code> modifier
         functions</a></dt>
     </dl>
   </dl>
@@ -40,25 +40,25 @@
   to define the class condition.</p>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-condition"></a>Class <code>condition</code></h3>
-<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 (an object whose type is a model of <a href="mutex_concept.html">Mutex</a> 
-  or one of its refinements). The mutex object must be locked prior to waiting 
-  on the <code>condition</code>, which is verified by passing a lock object (an 
-  object whose type is a model of <a href="lock_concept.html">Lock</a> or one 
-  of its refinements) to the <code>condition</code> object&#39;s <code>wait</code> 
-  functions. Upon blocking on the condition object, the thread unlocks the mutex 
-  object. When the thread returns from a call to one of the condition object's 
-  wait functions the mutex object is again locked. The tricky unlock/lock sequence 
-  is performed automatically by the <code> condition</code> object&#39;s <code>wait</code> 
+<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 (an object whose type is a model of <a href="mutex_concept.html">Mutex</a>
+  or one of its refinements). The mutex object must be locked prior to waiting
+  on the <code>condition</code>, which is verified by passing a lock object (an
+  object whose type is a model of <a href="lock_concept.html">Lock</a> or one
+  of its refinements) to the <code>condition</code> object&#39;s <code>wait</code>
+  functions. Upon blocking on the condition object, the thread unlocks the mutex
+  object. When the thread returns from a call to one of the condition object's
+  wait functions the mutex object is again locked. The tricky 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 
+<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>. 
+<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>
 <h4><a name="class-condition-synopsis"></a>Class <code>condition</code> synopsis</h4>
 <pre>
@@ -84,99 +84,99 @@ namespace boost
     };
 };
 </pre>
-<h4><a name="class-condition-ctors"></a>Class <code>condition</code> constructors 
+<h4><a name="class-condition-ctors"></a>Class <code>condition</code> constructors
   and destructor</h4>
 <pre>
 condition();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Constructs a <code>condition</code> object.</dt>
 </dl>
 <pre>
 ~condition();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Destroys <code>*this</code>.</dt>
 </dl>
-<h4><a name="class-condition-modifiers"></a>Class <code>condition</code> modifier 
+<h4><a name="class-condition-modifiers"></a>Class <code>condition</code> modifier
   functions</h4>
 <pre>
 void notify_one();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> If there is a thread waiting on <code>*this</code>, change 
+<dl class="function-semantics">
+  <dt><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.</dt>
-  <dt><b>Note:</b> If more than one thread is waiting on the condition, 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 
+  <dt><b>Note:</b> If more than one thread is waiting on the condition, 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 <code>condition</code> object's wait functions).</dt>
 </dl>
 <pre>
 void notify_all();
 </pre>
-<dl class="function-semantics"> 
-  <dt><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 
+<dl class="function-semantics">
+  <dt><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.</dt>
 </dl>
 <pre>
 template &lt;typename ScopedLock&gt;
     void wait(ScopedLock&amp; lock);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a> 
+<dl class="function-semantics">
+  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a>
     requirements.</dt>
-  <dt><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 
+  <dt><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.</dt>
-  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code> 
+  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code>
     if <code>!lock.locked()</code></dt>
-  <dt><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 
+  <dt><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.</dt>
 </dl>
 <pre>
 Template&lt;typename ScopedLock, typename Pr&gt;
     void wait(ScopedLock&amp; lock, Pr pred);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a> 
+<dl class="function-semantics">
+  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a>
     requirements, return from <code>pred()</code> convertible to bool.</dt>
   <dt><b>Effects:</b> As if: <code>while (!pred()) wait(lock)</code></dt>
-  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code> 
+  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code>
     if <code>!lock.locked()</code></dt>
 </dl>
 <pre>
 template &lt;typename ScopedLock&gt;
     bool timed_wait(ScopedLock&amp; lock, const <a href="xtime.html">xtime</a>&amp; XT);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a> 
+<dl class="function-semantics">
+  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a>
     requirements.</dt>
-  <dt><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 
+  <dt><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.</dt>
-  <dt><b>Returns:</b> <code>false</code> if <code>XT</code> is reached, otherwise 
+  <dt><b>Returns:</b> <code>false</code> if <code>XT</code> is reached, otherwise
     <code>true</code>.</dt>
-  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code> 
+  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code>
     if <code>!lock.locked()</code></dt>
-  <dt><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 
+  <dt><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.</dt>
 </dl>
 <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>
-<dl class="function-semantics"> 
-  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a> 
+<dl class="function-semantics">
+  <dt><b>Requires:</b> <code>ScopedLock</code> meets the <a href="lock_concept.html#ScopedLock">ScopedLock</a>
     requirements, return from <code>pred()</code> convertible to bool.</dt>
   <dt><b>Effects:</b> As if:<br>
     <pre>
@@ -188,82 +188,13 @@ while (!pred())
 return true;
 </pre>
   </dt>
-  <dt><b>Returns:</b> <code>false</code> if <code>XT</code> is reached, otherwise 
+  <dt><b>Returns:</b> <code>false</code> if <code>XT</code> is reached, otherwise
     <code>true</code>.</dt>
-  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code> 
+  <dt><b>Throws:</b> <code><a href="exceptions.html#class-lock_error">lock_error</a></code>
     if <code>!lock.locked()</code></dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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><a href="../example/condition.cpp">libs/thread/example/condition.cpp</a></p>
 <p>Typical output (dependent on scheduling policies) is:</p>
 <pre>
 sent: 0
@@ -277,18 +208,18 @@ received: 3
 sent: 4
 received: 4
 </pre>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/configuration.html b/doc/configuration.html
index 657710d0..c59ffc4b 100644
--- a/doc/configuration.html
+++ b/doc/configuration.html
@@ -7,88 +7,88 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Configuration</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#lib-defined-public">Public Library Defined Macros</a></dt>
   <dt><a href="#lib-defined-impl">Library Defined Implementation Macros</a></dt>
 </dl>
 <h2><a name="introduction"></a>Introduction</h2>
-<p><b>Boost.Threads</b> uses several configuration macros in <a href="../../config/config.htm">&lt;boost/config.hpp&gt;</a>, 
-  as well as configuration macros meant to be supplied by the application. These 
+<p><b>Boost.Threads</b> uses several configuration macros in <a href="../../config/config.htm">&lt;boost/config.hpp&gt;</a>,
+  as well as configuration macros meant to be supplied by the application. These
   macros are documented here.</p>
 <h2><a name="lib-defined-public"></a>Public Library Defined Macros</h2>
-<p>These macros are defined by <b>Boost.Threads</b> but are expected to be used 
+<p>These macros are defined by <b>Boost.Threads</b> but are expected to be used
   by application code.</p>
 <table summary="public library defined macros" cellspacing="10" width="100%">
-  <tr> 
+  <tr>
     <td><b>Macro</b></td>
     <td><b>Meaning</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td>BOOST_HAS_THREADS</td>
-    <td>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 multithreading runtimes 
-      (often determined by the compiler predefining the macro _MT) the BOOST_HAS_THREADS 
+    <td>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 multithreading runtimes
+      (often determined by the compiler predefining the macro _MT) the BOOST_HAS_THREADS
       macro remains undefined.</td>
   </tr>
 </table>
 <h2><a name="lib-defined-impl"></a>Library Defined Implementation Macros</h2>
-<p>These macros are defined by <b>Boost.Threads</b> and are implementation details 
+<p>These macros are defined by <b>Boost.Threads</b> and are implementation details
   of interest only to implementors.</p>
 <table summary="library defined implementation macros" cellspacing="10" width="100%">
-  <tr> 
+  <tr>
     <td><b>Macro</b></td>
     <td><b>Meaning</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td>BOOST_HAS_WINTHREADS</td>
-    <td>Indicates that the platform has the Microsoft Win32 threading libraries, 
+    <td>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> 
+  <tr>
     <td>BOOST_HAS_PTHREADS</td>
-    <td>Indicates that the platform has the POSIX pthreads libraries, and that 
+    <td>Indicates that the platform has the POSIX pthreads libraries, and that
       they should be used to implement <b>Boost.Threads</b>.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>BOOST_HAS_FTIME</td>
-    <td>Indicates that the implementation should use GetSystemTimeAsFileTime() 
-      and the FILETIME type to calculate the current time. This is an implementation 
+    <td>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> 
+  <tr>
     <td>BOOST_HAS_GETTTIMEOFDAY</td>
-    <td>Indicates that the implementation should use gettimeofday() to calculate 
+    <td>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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/definitions.html b/doc/definitions.html
index a0d225ed..ebcca272 100644
--- a/doc/definitions.html
+++ b/doc/definitions.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Definitions</h2>
     </td>
@@ -19,10 +19,10 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#definitions">Definitions</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#definition-thread">Thread</a></dt>
     <dt><a href="#definition-thread-safe">Thread-safe</a></dt>
     <dt><a href="#definition-thread-state">Thread State</a></dt>
@@ -37,40 +37,40 @@
 <hr>
 <h2><a name="introduction"></a>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 
+        "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 
+<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><a name="definitions"></a>Definitions</h2>
 <h3><a name="definition-thread"></a>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 multithreading environment always has 
+<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 multithreading 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 
+<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 
+  <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 
+  <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 
+  <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>
@@ -81,183 +81,183 @@
   <li>Automatic storage duration (stack) objects [3.7.2].</li>
 </ul>
 <h3><a name="definition-thread-safe"></a>Thread-safe</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 
+<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, 
+<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><a name="definition-thread-state"></a>Thread State</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> 
+  <tr>
     <td><b>State</b></td>
     <td><b>Description</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td>Ready</td>
     <td>Ready to run, but waiting for a processor.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Running</td>
-    <td>Currently executing on a processor. Zero or more threads may be running 
+    <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> 
+  <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]. 
+    <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> 
+  <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> 
+  <tr>
     <td><b>From</b></td>
     <td><b>To</b></td>
     <td><b>Cause</b></td>
   </tr>
-  <tr> 
-    <td> 
+  <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 
+    <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> 
+  <tr>
     <td>Ready</td>
     <td>Running</td>
     <td>Processor becomes available.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Running</td>
     <td>Ready</td>
     <td>Thread preempted.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Running</td>
     <td>Blocked</td>
-    <td>Thread calls a library function which waits for a resource or for the 
+    <td>Thread calls a library function which waits for a resource or for the
       completion of I/O.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Running</td>
     <td>Terminated</td>
-    <td>Thread returns from its initial function, calls a thread termination library 
-      function, or is canceled by some other thread calling a thread termination 
+    <td>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.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Blocked</td>
     <td>Ready</td>
-    <td>The resource being waited for becomes available, or the blocking library 
+    <td>The resource being waited for becomes available, or the blocking library
       function completes.</td>
   </tr>
-  <tr> 
+  <tr>
     <td>Terminated</td>
     <td>[none]</td>
-    <td>Thread is detached or joined by some other thread calling the appropriate 
+    <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 
+<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="definition-race-condition"></a>Race Condition</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 
+<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 
+<p>Race conditions can be prevented by serializing memory access using the tools
   provided by Boost.Threads.</p>
 <h3><a name="definition-deadlock"></a>Deadlock</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 
+<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="definition-starvation"></a>Starvation</h3>
-<p>The condition in which a thread is not making sufficient progress in its work 
+<p>The condition in which a thread is not making sufficient progress in its work
   during a given time interval.</p>
 <h3><a name="definition-priority-failure"></a>Priority Failure</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 
+<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>
 <h3><a name="definition-visibility"></a>Memory Visibility</h3>
-<p>An address [1.7] shall always point to the same memory byte, regardless of 
+<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 
+<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 
+<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> 
+  <tr>
     <td align="center"><b>Thread A</b></td>
     <td align="center"><b>Thread B</b></td>
   </tr>
-  <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 
+    <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, 
+  <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 
+    <td>The sequence point after a call to a library function which unlocks the
       same mutex.</td>
   </tr>
-  <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 
+    <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 
+  <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 
+    <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 
+<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 
+<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() 
+<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"></a>Acknowledgments</h2>
-<p>This document has been much improved by the incorporation of comments from 
+<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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/exceptions.html b/doc/exceptions.html
index e676394b..dadb2e3e 100644
--- a/doc/exceptions.html
+++ b/doc/exceptions.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/exceptions.hpp">boost/thread/exceptions.hpp</a>&gt;</h2>
     </td>
@@ -19,21 +19,21 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-lock_error">Class <code>lock_error</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-lock_error-synopsis">Class <code>lock_error</code> synopsis</a></dt>
-      <dt><a href="#class-lock_error-ctors">Class <code>lock_error</code> constructors 
+      <dt><a href="#class-lock_error-ctors">Class <code>lock_error</code> constructors
         and destructor</a></dt>
     </dl>
     <dt><a href="#class-thread_resource_error">Class <code>thread_resource_error</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-thread_resource_error-synopsis">Class <code>thread_resource_error</code> 
+    <dl class="page-index">
+      <dt><a href="#class-thread_resource_error-synopsis">Class <code>thread_resource_error</code>
         synopsis</a></dt>
-      <dt><a href="#class-thread_resource_error-ctors">Class <code>thread_resource_error</code> 
+      <dt><a href="#class-thread_resource_error-ctors">Class <code>thread_resource_error</code>
         constructors and destructor</a></dt>
     </dl>
   </dl>
@@ -44,67 +44,67 @@
   to define the exception types that may be thrown by <b>Boost.Threads</b> classes.</p>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-lock_error"></a>Class <code>lock_error</code></h3>
-<p>The lock_error 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 
+<p>The lock_error 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>
 <h4><a name="class-lock_error-synopsis"></a>Class <code>lock_error</code> synopsis</h4>
 <pre>
 namespace boost
 {
     class lock_error : public std::logical_error
-	{
-	public:
-	    lock_error();
-	};
+    {
+    public:
+        lock_error();
+    };
 };
 </pre>
-<h4><a name="class-lock_error-ctors"></a>Class <code>lock_error</code> constructors 
+<h4><a name="class-lock_error-ctors"></a>Class <code>lock_error</code> constructors
   and destructor</h4>
 <pre>
 lock_error();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Constructs a <code>lock_error</code> object.</dt>
 </dl>
 <h3><a name="class-thread_resource_error"></a>Class <code>thread_resource_error</code></h3>
-<p>The thread_resource_error class defines an exception type that is thrown by 
-  constructors in the Boost.Threads library when thread related resources can 
-  not be acquired. This does not include memory allocation failures which instead 
+<p>The thread_resource_error class defines an exception type that is thrown by
+  constructors in the Boost.Threads library when thread related resources can
+  not be acquired. This does not include memory allocation failures which instead
   throw std::bad_alloc. </p>
-<h4><a name="class-thread_resource_error-synopsis"></a>Class <code>thread_resource_error</code> 
+<h4><a name="class-thread_resource_error-synopsis"></a>Class <code>thread_resource_error</code>
   synopsis</h4>
 <pre>
 namespace boost
 {
     class thread_resource_error : public std::runtime_error
-	{
-	public:
-	    thread_resource_error();
-	};
+    {
+    public:
+        thread_resource_error();
+    };
 };
 </pre>
-<h4><a name="class-thread_resource_error-ctors"></a>Class <code>thread_resource_error</code> 
+<h4><a name="class-thread_resource_error-ctors"></a>Class <code>thread_resource_error</code>
   constructors and destructor</h4>
 <pre>
 thread_resource_error();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Constructs a <code>thread_resource_error</code> object.</dt>
 </dl>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/faq.html b/doc/faq.html
index 07edfa71..b01fadc5 100644
--- a/doc/faq.html
+++ b/doc/faq.html
@@ -7,84 +7,84 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Frequently Asked Questions (FAQs)</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#question1">1. Are lock objects thread safe?</a></dt>
-  <dt><a href="#question2a">2a. Why was <b>Boost.Threads</b> modeled after (specific 
+  <dt><a href="#question2a">2a. Why was <b>Boost.Threads</b> modeled after (specific
     library name)?</a></dt>
-  <dt><a href="#question2b">2b. Why wasn't <b>Boost.Threads</b> modeled after 
+  <dt><a href="#question2b">2b. Why wasn't <b>Boost.Threads</b> modeled after
     (specific library name)?</a></dt>
   <dt><a href="#question3">3. Why do mutexes have noncopyable semantics?</a></dt>
-  <dt><a href="#question4">4. How can you prevent deadlock from occurring when 
+  <dt><a href="#question4">4. How can you prevent deadlock from occurring when
     a thread must lock multiple mutexes?</a></dt>
-  <dt><a href="#question5">5. Don't noncopyable mutex semantics mean that a class 
+  <dt><a href="#question5">5. Don't noncopyable mutex semantics mean that a class
     with a mutex member will be noncopyable as well?</a></dt>
-  <dt><a href="#question6">6. How can you lock a mutex member in a const member 
+  <dt><a href="#question6">6. How can you lock a mutex member in a const member
     function (in order to implement the monitor pattern)?</a></dt>
-  <dt><a href="#question7">7. Why supply condition variables rather than event 
+  <dt><a href="#question7">7. Why supply condition variables rather than event
     variables?</a></dt>
   <dt><a href="#question8">8. Why isn't thread cancellation or termination provided?</a></dt>
-  <dt><a href="#question9">9. Is it safe for threads to share automatic storage 
+  <dt><a href="#question9">9. Is it safe for threads to share automatic storage
     duration (stack) objects via pointers or references?</a></dt>
   <dt><a href="#question10">10. Why has class semaphore disappeared?</a></dt>
 </dl>
-<h2><a name="question1"></a>1. Are lock objects <a href="definitions.html#definition-thread-safe"> 
+<h2><a name="question1"></a>1. Are lock objects <a href="definitions.html#definition-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 
+<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 
+        "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><a name="question2a"></a>2a. Why was <b>Boost.Threads</b> modeled after (specific 
+<h2><a name="question2a"></a>2a. Why was <b>Boost.Threads</b> 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 the Win32 threading API. But the Boost.Threads design 
+<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 the Win32 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><a name="question2b"></a>2b. Why wasn&#39;t Boost.Threads modeled after (specific 
+<h2><a name="question2b"></a>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 
+<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><a name="question3"></a>3. Why do <a href="mutex_concept.html">Mutexes</a> 
+<h2><a name="question3"></a>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 
+<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><a name="question4"></a>4. How can you prevent <a href="definitions.html#Deadlock"> 
+<h2><a name="question4"></a>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 
+<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><a name="question5"></a>5. Don&#39;t noncopyable <a href="mutex_concept.html">mutex</a> 
+<h2><a name="question5"></a>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 
+<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 
+        "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
@@ -96,7 +96,7 @@ public:
       : 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)
@@ -104,20 +104,20 @@ public:
       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);
@@ -128,56 +128,56 @@ public:
       boost::mutex::scoped_lock scoped_lock(m_mutex);
       return ++m_value;
    }
-   
+
 private:
    mutable boost::mutex m_mutex;
    int m_value;
 };
 </pre>
-<h2><a name="question6"></a>6. How can you lock a <a href="mutex_concept.html">mutex</a> 
+<h2><a name="question6"></a>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 (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 
+<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 (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.</p>
-<h2><a name="question7"></a>7. Why supply <a href="condition.html">condition variables</a> 
+<h2><a name="question7"></a>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">[Hoare 
+        "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">[Hoare
   74]</a> and <a href="bibliography.html#Schmidt-00">[Schmidt 00]</a>.</p>
-<h2><a name="question8"></a>8. Why isn&#39;t thread cancellation or termination 
+<h2><a name="question8"></a>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) 
+<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><a name="question9"></a>9. Is it safe for threads to share automatic storage 
+<h2><a name="question9"></a>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 
+<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><a name="question10"></a>10. Why has class semaphore disappeared?</h2>
-<p>Semaphore was removed as too error prone. The same effect can be achieved with 
+<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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/index.html b/doc/index.html
index 3e5baadd..653d8429 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Index</h2>
     </td>
@@ -19,16 +19,16 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="index"> 
+<dl class="index">
   <dt><a href="overview.html">Overview</a></dt>
   <dt><a href="mutex_concept.html">Mutex Concepts</a></dt>
-  <dl class="index"> 
+  <dl class="index">
     <dt><a href="mutex_concept.html#Mutex">Mutex</a></dt>
     <dt><a href="mutex_concept.html#TryMutex">TryMutex</a></dt>
     <dt><a href="mutex_concept.html#TimedMutex">TimedMutex</a></dt>
   </dl>
   <dt><a href="lock_concept.html">Lock Concepts</a></dt>
-  <dl class="index"> 
+  <dl class="index">
     <dt><a href="lock_concept.html#Lock">Lock</a></dt>
     <dt><a href="lock_concept.html#ScopedLock">ScopedLock</a></dt>
     <dt><a href="lock_concept.html#ScopedTryLock">ScopedTryLock</a></dt>
@@ -44,85 +44,100 @@
 	  </dl>
 	</dl>
     <dt><a href="condition.html"><code>&lt;boost/thread/condition.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="condition.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="condition.html#class-condition"><code>condition</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="exceptions.html"><code>&lt;boost/thread/exceptions.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="exceptions.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="exceptions.html#class-lock_error"><code>lock_error</code></a></dt>
         <dt><a href="exceptions.html#class-thread_resource_error"><code>thread_resource_error</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="mutex.html"><code>&lt;boost/thread/mutex.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="mutex.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="mutex.html#class-mutex"><code>mutex</code></a></dt>
         <dt><a href="mutex.html#class-try_mutex"><code>try_mutex</code></a></dt>
         <dt><a href="mutex.html#class-timed_mutex"><code>timed_mutex</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="once.html"><code>&lt;boost/thread/once.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="once.html#macros">Macros</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="once.html#macro-BOOST_ONCE_INIT"><code>BOOST_ONCE_INIT</code></a></dt>
       </dl>
       <dt><a href="once.html#types">Types</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="once.html#type-once_flag"><code>once_flag</code></a></dt>
       </dl>
       <dt><a href="once.html#functions">Functions</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="once.html#function-call_once"><code>call_once</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="recursive_mutex.html"><code>&lt;boost/thread/recursive_mutex.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="recursive_mutex.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="recursive_mutex.html#class-recursive_mutex"><code>recursive_mutex</code></a></dt>
         <dt><a href="recursive_mutex.html#class-recursive_try_mutex"><code>recursive_try_mutex</code></a></dt>
         <dt><a href="recursive_mutex.html#class-recursive_timed_mutex"><code>recursive_timed_mutex</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="thread.html"><code>&lt;boost/thread/thread.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="thread.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="thread.html#class-thread"><code>thread</code></a></dt>
         <dt><a href="thread.html#class-thread_group"><code>thread_group</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="tss.html"><code>&lt;boost/thread/tss.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="tss.html#classes">Classes</a></dt>
-      <dl class="index"> 
+      <dl class="index">
         <dt><a href="tss.html#class-thread_specific_ptr"><code>thread_specific_ptr</code></a></dt>
       </dl>
     </dl>
+  </dl>
+  <dl class="index">
     <dt><a href="xtime.html"><code>&lt;boost/thread/xtime.hpp&gt;</code></a></dt>
-    <dl class="index"> 
+    <dl class="index">
       <dt><a href="xtime.html#values">Values</a></dt>
-      <dl class="page-index"> 
+      <dl class="page-index">
         <dt><a href="xtime.html#value-spec"><code>TIME_UTC</code></a></dt>
       </dl>
       <dt><a href="xtime.html#classes">Classes</a></dt>
-      <dl class="page-index"> 
+      <dl class="page-index">
         <dt><a href="xtime.html#class-xtime"><code>xtime</code></a></dt>
       </dl>
       <dt><a href="xtime.html#functions">Functions</a></dt>
-      <dl class="page-index"> 
+      <dl class="page-index">
         <dt><a href="xtime.html#function-xtime_get"><code>xtime_get</code></a></dt>
       </dl>
     </dl>
   </dl>
   <dt><a href="configuration.html">Configuration Information</a></dt>
+  <dt><a href="build.html">Building and Testing</a></dt>
   <dt><a href="introduction.html">Introduction to Design</a></dt>
   <dt><a href="rationale.html">Rationale</a></dt>
   <dt><a href="definitions.html">Definitions</a></dt>
@@ -131,18 +146,18 @@
   <dt><a href="acknowledgments.html">Acknowledgments</a></dt>
 </dl>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/introduction.html b/doc/introduction.html
index 4b499898..a3ef3bbf 100644
--- a/doc/introduction.html
+++ b/doc/introduction.html
@@ -7,153 +7,153 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Introduction to Design</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#motivation">Motivation</a></dt>
   <dt><a href="#goals">Goals</a></dt>
   <dt><a href="#phases">Iterative Phases</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#phase1">Phase 1, Synchronization Primitives</a></dt>
     <dt><a href="#phase2">Phase 2, Thread Management and Thread Specific Storage</a></dt>
     <dt><a href="#next-phase">The Next Phase</a></dt>
   </dl>
 </dl>
 <h2><a name="motivation"></a>Motivation</h2>
-<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 
+<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 
+<p>The <b>Boost.Threads</b> library is an attempt to define a portable interface
   for writing parallel processes in C++.</p>
 <h2><a name="goals"></a>Goals</h2>
-<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 
+<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, 
+  <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 
+  <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 
+      <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, 
+      <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 
+      <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. 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 
+  <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. 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.</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 
+  <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>
 <h2><a name="phases"></a>Iterative Phases</h2>
-<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. 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 
+<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. 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 
+<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>
 <h3><a name="phase1"></a>Phase 1, Synchronization Primitives</h3>
-<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 multithreaded 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 
+<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 multithreaded 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> 
-  and <a href="exceptions.html#class-lock_error">lock_error</a>. These are considered 
-  the &quot;core&quot; synchronization primitives, though there are others that 
+<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>
+  and <a href="exceptions.html#class-lock_error">lock_error</a>. These are considered
+  the &quot;core&quot; synchronization primitives, though there are others that
   will be added in later phases.</p>
 <h3><a name="phase2"></a>Phase 2, Thread Management and Thread Specific Storage</h3>
-<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 multithreaded 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="tss.html#class-thread_specific_ptr">thread_specific_ptr</a> types. 
-  With these additions the <b>Boost.Threads</b> library can be considered minimal 
+<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 multithreaded 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="tss.html#class-thread_specific_ptr">thread_specific_ptr</a> types.
+  With these additions the <b>Boost.Threads</b> library can be considered minimal
   but complete.</p>
 <h3><a name="next-phase"></a>The Next Phase</h3>
-<p>The next phase will address more advanced synchronization concepts, such as 
+<p>The next phase will address more advanced synchronization concepts, such as
   read/write mutexes and barriers.</p>
 <hr>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/lock_concept.html b/doc/lock_concept.html
index c18cc899..8b587d6f 100644
--- a/doc/lock_concept.html
+++ b/doc/lock_concept.html
@@ -7,21 +7,21 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">ScopedLock Concept</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#concept-requirements">Concept Requirements</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#Lock-concept">Lock Concept</a></dt>
     <dt><a href="#ScopedLock-concept">ScopedLock Concept</a></dt>
     <dt><a href="#ScopedTryLock-concept">ScopedTryLock Concept</a></dt>
@@ -29,166 +29,166 @@
   </dl>
 </dl>
 <h2><a name="introduction"></a>Introduction</h2>
-<p>A lock object provides a safe means for locking and unlocking a mutex object 
-  (an object whose type is a model of <a href="mutex_concept.html">Mutex</a> or 
-  one of its refinements). 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-concept">ScopedLock</a> concept, with <a href="#ScopedTryLock-concept">ScopedTryLock</a> 
-  and <a href="#ScopedTimedLock-concept">ScopedTimedLock</a> refinements, formalize 
+<p>A lock object provides a safe means for locking and unlocking a mutex object
+  (an object whose type is a model of <a href="mutex_concept.html">Mutex</a> or
+  one of its refinements). 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-concept">ScopedLock</a> concept, with <a href="#ScopedTryLock-concept">ScopedTryLock</a>
+  and <a href="#ScopedTimedLock-concept">ScopedTimedLock</a> refinements, formalize
   the requirements.</p>
-<p>Lock objects are constructed with a reference to a mutex object and typically 
-  acquire ownership of the mutex object by setting its state to locked. They also 
-  ensure ownership is relinquished in the destructor. Lock objects also expose 
-  functions to query the lock status and to manually lock and unlock the mutex 
+<p>Lock objects are constructed with a reference to a mutex object and typically
+  acquire ownership of the mutex object by setting its state to locked. They also
+  ensure ownership is relinquished in the destructor. Lock objects also expose
+  functions to query the lock status and to manually lock and unlock the mutex
   object.</p>
-<p>Lock objects are meant to be short lived, expected to be used at block scope 
-  only. The lock objects are not <a href="definitions.html#definition-thread-safe">thread-safe</a>. 
-  Lock objects must maintain state to indicate whether or not they&#39;ve been 
-  locked and this state is not protected by any synchronization concepts. For 
+<p>Lock objects are meant to be short lived, expected to be used at block scope
+  only. The lock objects are not <a href="definitions.html#definition-thread-safe">thread-safe</a>.
+  Lock objects 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 a lock object should never be shared between multiple threads.</p>
 <h2><a name="concept-requirements"></a>Concept Requirements</h2>
 <h3><a name="Lock-concept"></a>Lock Concept</h3>
-<p>For a Lock 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 
+<p>For a Lock 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>
 <table summary="Lock expressions" border="1" cellpadding="5">
-  <tr> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>(&amp;lk)-&gt;~L();</code></td>
     <td><code>if (locked()) unlock();</code></td>
   </tr>
-  <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 object has been 
+    <td>Returns type void*, non-zero if if the associated mutex object has been
       locked by <code>clk</code>, otherwise 0.</td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>clk.locked()</code></td>
-    <td>Returns a <code>bool</code>, <code>(&amp;clk)-&gt;operator const void*() 
+    <td>Returns a <code>bool</code>, <code>(&amp;clk)-&gt;operator const void*()
       != 0</code></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>lk.lock()</code></td>
-    <td>Throws <code>lock_error</code> if <code>locked()</code>. If the associated 
-      mutex object 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. If the 
-      associated mutex object is already locked by the same thread the behavior 
-      is dependent on the <a href="mutex_concept.html#locking-strategies">locking 
+    <td>Throws <code>lock_error</code> if <code>locked()</code>. If the associated
+      mutex object 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. If the
+      associated mutex object is already locked by the same thread the behavior
+      is dependent on the <a href="mutex_concept.html#locking-strategies">locking
       strategy</a> of the associated mutex object.<br>
       Postcondition: <code>locked() == true</code></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>lk.unlock()</code></td>
-    <td>If <code>!locked()</code>, throws <code>lock_error</code>, otherwise unlocks 
+    <td>If <code>!locked()</code>, throws <code>lock_error</code>, otherwise unlocks
       the associated mutex.<br>
       Postcondition: <code>!locked()</code></td>
   </tr>
 </table>
 <h3><a name="ScopedLock-concept"></a>ScopedLock Concept</h3>
-<p>A ScopedLock is a refinement of <a href="#Lock">Lock</a>. 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-concept">Mutex</a> 
-  requirements, and an object <code>b</code> of type <code>bool</code>, the following 
+<p>A ScopedLock is a refinement of <a href="#Lock">Lock</a>. 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-concept">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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then calls <code>lock()</code></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m,b);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then if <code>b</code>, calls <code>lock()</code></td>
   </tr>
 </table>
 <h3><a name="ScopedTryLock-concept"></a>ScopedTryLock Concept</h3>
-<p>A ScopedTryLock is a refinement of <a href="#Lock-concept">Lock</a>. 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-concept">TryMutex</a> 
-  requirements, and an object <code>b</code> of type <code>bool</code>, the following 
+<p>A ScopedTryLock is a refinement of <a href="#Lock-concept">Lock</a>. 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-concept">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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then calls <code>try_lock()</code></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m,b);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then if <code>b</code>, calls <code> lock()</code></td>
   </tr>
-  <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 object, returning <code>true</code> if the 
-      lock attempt is successful, otherwise <code>false</code>. If the associated 
-      mutex object is already locked by the same thread the behavior is dependent 
-      on the <a href="mutex_concept.html#locking-strategies">locking strategy</a> 
+    <td>If locked(), throws <code>lock_error</code>. Makes a non-blocking attempt
+      to lock the associated mutex object, returning <code>true</code> if the
+      lock attempt is successful, otherwise <code>false</code>. If the associated
+      mutex object is already locked by the same thread the behavior is dependent
+      on the <a href="mutex_concept.html#locking-strategies">locking strategy</a>
       of the associated mutex object.</td>
   </tr>
 </table>
 <h3><a name="ScopedTimedLock-concept"></a>ScopedTimedLock Concept</h3>
-<p>A ScopedTimedLock is a refinement of <a href="#Lock">Lock</a>. 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>, 
+<p>A ScopedTimedLock is a refinement of <a href="#Lock">Lock</a>. 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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m,t);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then calls <code> timed_lock(t)</code></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code>L lk(m,b);</code></td>
-    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code> 
+    <td>Constructs an object <code>lk</code>, and associates mutex object <code>m</code>
       with it, then if <code>b</code>, calls <code> lock()</code></td>
   </tr>
-  <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 object, and returns <code>true</code> if successful within the specified 
-      time <code>t</code>, otherwise <code>false</code>. If the associated mutex 
-      object is already locked by the same thread the behavior is dependent on 
-      the <a href="mutex_concept.html#locking-strategies">locking strategy</a> 
+    <td>If locked(), throws lock_error. Makes a blocking attempt to lock the associated
+      mutex object, and returns <code>true</code> if successful within the specified
+      time <code>t</code>, otherwise <code>false</code>. If the associated mutex
+      object is already locked by the same thread the behavior is dependent on
+      the <a href="mutex_concept.html#locking-strategies">locking strategy</a>
       of the associated mutex object.</td>
   </tr>
 </table>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/mutex.html b/doc/mutex.html
index 8491ffc5..c7a28ffa 100644
--- a/doc/mutex.html
+++ b/doc/mutex.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/mutex.hpp">boost/thread/mutex.hpp</a>&gt;</h2>
     </td>
@@ -19,31 +19,31 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-mutex">Class <code>mutex</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-mutex-synopsis">Class <code>mutex</code> synopsis</a></dt>
-      <dt><a href="#class-mutex-ctors">Class <code>mutex</code> constructors and 
+      <dt><a href="#class-mutex-ctors">Class <code>mutex</code> constructors and
         destructor</a></dt>
     </dl>
   </dl>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-try_mutex">Class <code>try_mutex</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-try_mutex-synopsis">Class <code>try_mutex</code> synopsis</a></dt>
-      <dt><a href="#class-try_mutex-ctors">Class <code>try_mutex</code> constructors 
+      <dt><a href="#class-try_mutex-ctors">Class <code>try_mutex</code> constructors
         and destructor</a></dt>
     </dl>
   </dl>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-timed_mutex">Class <code>timed_mutex</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-timed_mutex-synopsis">Class <code>timed_mutex</code> 
+    <dl class="page-index">
+      <dt><a href="#class-timed_mutex-synopsis">Class <code>timed_mutex</code>
         synopsis</a></dt>
-      <dt><a href="#class-timed_mutex-ctors">Class <code>timed_mutex</code> constructors 
+      <dt><a href="#class-timed_mutex-ctors">Class <code>timed_mutex</code> constructors
         and destructor</a></dt>
     </dl>
   </dl>
@@ -57,35 +57,35 @@
         "#timed_mutex Synopsis">timed_mutex</a></code> classes.</p>
 <p>The <code><a href="#mutex Synopsis">mutex</a></code>, <code><a href=
         "#try_mutex Synopsis">try_mutex</a></code> and <code><a href=
-        "#timed_mutex Synopsis">timed_mutex</a></code> classes are models of <a href="mutex_concept.html#Mutex-concept">Mutex</a>, 
-  <a href="mutex_concept.html#TryMutex-concept">TryMutex</a>, and <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a> 
-  respectively. These types should be used to non-recursively synchronize access 
-  to shared resources. For recursive locking mechanics, see the <a href="recursive_mutex.html">recursive 
+        "#timed_mutex Synopsis">timed_mutex</a></code> classes are models of <a href="mutex_concept.html#Mutex-concept">Mutex</a>,
+  <a href="mutex_concept.html#TryMutex-concept">TryMutex</a>, and <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a>
+  respectively. These types should be used to non-recursively synchronize access
+  to shared resources. For recursive locking mechanics, see the <a href="recursive_mutex.html">recursive
   mutexes</a> supplied by <b>Boost.Threads</b>.</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 
+<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> 
+  <tr>
     <td><b>Mutex Class</b></td>
     <td><b>Lock name</b></td>
     <td><b>Lock Concept</b></td>
   </tr>
-  <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"><a href="lock_concept.html#ScopedLock"> ScopedLock</a></td>
   </tr>
-  <tr> 
-    <td valign="top"><code><a href="#try_mutex Synopsis"> try_mutex</a></code> 
+  <tr>
+    <td valign="top"><code><a href="#try_mutex Synopsis"> try_mutex</a></code>
     </td>
     <td valign="middle"><code>scoped_lock<br>
       scoped_try_lock</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> 
+  <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>
@@ -95,22 +95,22 @@
       <a href="lock_concept.html#ScopedTimedLock"> ScopedTimedLock</a></td>
   </tr>
 </table>
-<p>The <code>mutex</code>, <code>try_mutex</code> and <code>timed_mutex</code> 
-  classes use an <code>Unspecified</code> <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 
+<p>The <code>mutex</code>, <code>try_mutex</code> and <code>timed_mutex</code>
+  classes use an <code>Unspecified</code> <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 <code>NDEBUG</code> is not defined.</p>
-<p>Like all the <b>Boost.Threads</b> <a href="mutex_concept.html">mutex models</a>, 
-  the <code>mutex</code>, <code>try_mutex</code> and <code> timed_mutex</code> 
-  leave the <a href="mutex_concept.html#SchedulingPolicies">scheduling policy</a> 
-  as <code> Unspecified</code>. Programmers should make no assumptions about the 
+<p>Like all the <b>Boost.Threads</b> <a href="mutex_concept.html">mutex models</a>,
+  the <code>mutex</code>, <code>try_mutex</code> and <code> timed_mutex</code>
+  leave the <a href="mutex_concept.html#SchedulingPolicies">scheduling policy</a>
+  as <code> Unspecified</code>. Programmers should make no assumptions about the
   order in which waiting threads acquire a lock.</p>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-mutex"></a>Class <code>mutex</code></h3>
-<p>The <code>mutex</code> class is a model of <a href="mutex_concept.html#Mutex-concept">Mutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>mutex</code> class is a model of <a href="mutex_concept.html#Mutex-concept">Mutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
 <h4><a name="class-mutex-synopsis"></a>Class <code>mutex</code> synopsis</h4>
 <pre>
@@ -121,31 +121,31 @@ namespace boost
     {
     public:
         typedef <i>[implementation defined; see <a href="#Introduction">Introduction</a>]</i> scoped_lock;
-        
+
         mutex();
         ~mutex();
     };
 };
 </pre>
-<h4><a name="class-mutex-ctors"></a>Class <code>mutex</code> constructors and 
+<h4><a name="class-mutex-ctors"></a>Class <code>mutex</code> constructors and
   destructor</h4>
 <pre>
 mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h3><a name="class-try_mutex"></a>Class <code>try_mutex</code></h3>
-<p>The <code>try_mutex</code> class is a model of <a href="mutex_concept.html#TryMutex-concept">TryMutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>try_mutex</code> class is a model of <a href="mutex_concept.html#TryMutex-concept">TryMutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
 <h4><a name="class-try_mutex-synopsis"></a>Class <code>try_mutex</code> synopsis</h4>
 <pre>
@@ -157,31 +157,31 @@ namespace boost
     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>
-<h4><a name="class-try_mutex-ctors"></a>Class <code>try_mutex</code> constructors 
+<h4><a name="class-try_mutex-ctors"></a>Class <code>try_mutex</code> constructors
   and destructor</h4>
 <pre>
 try_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~try_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h3><a name="class-timed_mutex"></a>Class <code>timed_mutex</code></h3>
-<p>The <code>timed_mutex</code> class is a model of <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>timed_mutex</code> class is a model of <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
 <h4><a name="class-timed_mutex-synopsis"></a>Class <code>timed_mutex</code> synopsis</h4>
 <pre>
@@ -194,75 +194,30 @@ namespace boost
         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>
-<h4><a name="class-timed_mutex-ctors"></a>Class <code>timed_mutex</code> constructors 
+<h4><a name="class-timed_mutex-ctors"></a>Class <code>timed_mutex</code> constructors
   and destructor</h4>
 <pre>
 timed_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~timed_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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()
-{
-    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);
-      
-    thrds.join_all();
-   
-    return 0;
-}
-</pre>
+<p><a href="../example/mutex.cpp">libs/thread/example/mutex.cpp</a></p>
 <p>The output is:</p>
 <pre>
 count == 1
@@ -271,18 +226,18 @@ count == 3
 count == 4
 </pre>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/mutex_concept.html b/doc/mutex_concept.html
index 20653d19..a4a2fbf7 100644
--- a/doc/mutex_concept.html
+++ b/doc/mutex_concept.html
@@ -7,33 +7,33 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> <a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../c++boost.gif" border="0"></a> 
+  <tr>
+    <td valign="top" width="300"> <a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../c++boost.gif" border="0"></a>
     </td>
-    <td valign="top"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Mutex Concept</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#locking-strategies">Locking Strategies</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#locking-strategy-recursive">Recursive</a></dt>
     <dt><a href="#locking-strategy-checked">Checked</a></dt>
     <dt><a href="#locking-strategy-unchecked">Unchecked</a></dt>
     <dt><a href="#locking-strategy-unspecified">Unspecified</a></dt>
   </dl>
   <dt><a href="#scheduling-policies">Scheduling Policies</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#scheduling-policy-FIFO">FIFO</a></dt>
     <dt><a href="#scheduling-policy-priority-driven">Priority Driven</a></dt>
     <dt><a href="#scheduling-policy-unspecified">Unspecified</a></dt>
   </dl>
   <dt><a href="#concept-requirements">Concept Requirements</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#Mutex-concept">Mutex Concept</a></dt>
     <dt><a href="#TryMutex-concept">TryMutex Concept</a></dt>
     <dt><a href="#TimedMutex-concept">TimedMutex Concept</a></dt>
@@ -41,155 +41,155 @@
   <dt><a href="#models">Models</a></dt>
 </dl>
 <h2><a name="introduction"></a>Introduction</h2>
-<p>A mutex (short for mutual-exclusion) object is used to 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 <b>Boost.Threads</b> mutex object (an object 
-  whose type is a model of <a href="#Mutex-concept">Mutex</a> or one of it's 
-  refinements), 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 object, allowing another thread to acquire the 
+<p>A mutex (short for mutual-exclusion) object is used to 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 <b>Boost.Threads</b> mutex object (an object
+  whose type is a model of <a href="#Mutex-concept">Mutex</a> or one of it's
+  refinements), 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 object, allowing another thread to acquire the
   lock and use the shared resource.</p>
-<p>Traditional C thread APIs, like POSIX threads or the Windows thread APIs, expose 
-  functions to lock and unlock a mutex object. 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 
-  object would become even greater. When exceptions are thrown, it becomes nearly 
-  impossible to ensure that the mutex object is unlocked properly when using these 
+<p>Traditional C thread APIs, like POSIX threads or the Windows thread APIs, expose
+  functions to lock and unlock a mutex object. 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
+  object would become even greater. When exceptions are thrown, it becomes nearly
+  impossible to ensure that the mutex object 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 mutex 
-  objects. With this pattern, a <a href="lock_concept.html">Lock</a> concept is 
-  employed where the lock object&#39;s constructor locks the associated mutex 
-  object 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 object: lock and unlock functions are not exposed 
-  by any <b>Boost.Threads</b> mutex objects. This helps to ensure safe usage patterns, 
+<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 mutex
+  objects. With this pattern, a <a href="lock_concept.html">Lock</a> concept is
+  employed where the lock object&#39;s constructor locks the associated mutex
+  object 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 object: lock and unlock functions are not exposed
+  by any <b>Boost.Threads</b> mutex objects. This helps to ensure safe usage patterns,
   especially when code throws exceptions.</p>
 <h2><a name="locking-strategies"></a>Locking Strategies</h2>
-<p>Every mutex object follows one of several locking strategies. These strategies 
-  define the semantics for the locking operation when the calling thread already 
+<p>Every mutex object 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 object.</p>
 <h3><a name="locking-strategy-recursive"></a>Recursive</h3>
-<p>With a recursive locking strategy when a thread attempts to acquire a lock 
-  on the mutex object 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 object, and a lock object, which even for a recursive mutex 
-  object cannot have any of its lock functions called multiple times without first 
+<p>With a recursive locking strategy when a thread attempts to acquire a lock
+  on the mutex object 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 object, and a lock object, which even for a recursive mutex
+  object cannot have any of its lock functions 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 
-  object&#39;s state returns to unlocked. Since mutex objects in <b>Boost.Threads</b> 
-  expose locking functionality only through lock concepts, a thread will always 
-  unlock a mutex object 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 
+<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
+  object&#39;s state returns to unlocked. Since mutex objects in <b>Boost.Threads</b>
+  expose locking functionality only through lock concepts, a thread will always
+  unlock a mutex object 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#class-recursive_mutex">recursive_mutex</a>, 
-  <a href="recursive_mutex.html#class-recursive_try_mutex">recursive_try_mutex</a> 
-  and <a href="recursive_mutex.html#class-recursive_timed_mutex">recursive_timed_mutex</a> 
+<p>Classes <a href="recursive_mutex.html#class-recursive_mutex">recursive_mutex</a>,
+  <a href="recursive_mutex.html#class-recursive_try_mutex">recursive_try_mutex</a>
+  and <a href="recursive_mutex.html#class-recursive_timed_mutex">recursive_timed_mutex</a>
   use this locking strategy.</p>
 <h3><a name="locking-strategy-checked"></a>Checked</h3>
-<p>With a checked locking strategy when a thread attempts to acquire a lock on 
-  the mutex object 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 object 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="exceptions.html#class-lock_error"> 
+<p>With a checked locking strategy when a thread attempts to acquire a lock on
+  the mutex object 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 object 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="exceptions.html#class-lock_error">
   lock_error</a> would be thrown in these cases.</p>
-<p><b>Boost.Threads</b> does not currently provide any mutex objects that use 
+<p><b>Boost.Threads</b> does not currently provide any mutex objects that use
   this strategy.</p>
 <h3><a name="locking-strategy-unchecked"></a>Unchecked</h3>
-<p>With an unchecked locking strategy when a thread attempts to acquire a lock 
-  on a mutex object for which the thread already owns a lock the operation will 
-  <a href="definitions.html#definition-deadlock">deadlock</a>. In general this 
-  locking strategy is less safe than a checked or recursive strategy, but it&#39;s 
+<p>With an unchecked locking strategy when a thread attempts to acquire a lock
+  on a mutex object for which the thread already owns a lock the operation will
+  <a href="definitions.html#definition-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 objects that use 
+<p><b>Boost.Threads</b> does not currently provide any mutex objects that use
   this strategy.</p>
 <h3><a name="locking-strategy-unspecified"></a>Unspecified</h3>
-<p>With an unspecified locking strategy, when a thread attempts to acquire a lock 
-  on a mutex object for which the thread already owns a lock the operation results 
+<p>With an unspecified locking strategy, when a thread attempts to acquire a lock
+  on a mutex object for which the thread already owns a lock the operation results
   in <b>undefined behavior</b>.</p>
-<p>In general a mutex object with an unspecified locking strategy is unsafe, and 
-  it requires programmer discipline to use the mutex object 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#class-mutex">mutex</a>, <a href="mutex.html#class-try_mutex">try_mutex</a> 
-  and <a href="mutex.html#class-timed_mutex">timed_mutex</a> use this locking 
+<p>In general a mutex object with an unspecified locking strategy is unsafe, and
+  it requires programmer discipline to use the mutex object 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#class-mutex">mutex</a>, <a href="mutex.html#class-try_mutex">try_mutex</a>
+  and <a href="mutex.html#class-timed_mutex">timed_mutex</a> use this locking
   strategy despite the lack of safety.</p>
 <h2><a name="scheduling-policies"></a>Scheduling Policies</h2>
-<p>Every mutex object follows one of several scheduling policies. These policies 
-  define the semantics when the mutex object is unlocked and there is more than 
-  one thread waiting to acquire a lock. In other words, the policy defines which 
+<p>Every mutex object follows one of several scheduling policies. These policies
+  define the semantics when the mutex object 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="scheduling-policy-FIFO"></a>FIFO</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 
+<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 object's lock.</p>
 <h3><a name="scheduling-policy-priority-driven"></a>Priority Driven</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 object 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 object's 
-  lock one of the other scheduling priorities will determine which thread shall 
+<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 object 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 object's
+  lock one of the other scheduling priorities will determine which thread shall
   acquire the lock.</p>
 <h3><a name="scheduling-policy-unspecified"></a>Unspecified</h3>
-<p>The mutex object does not specify a scheduling policy. In order to ensure portability, 
+<p>The mutex object does not specify a scheduling policy. In order to ensure portability,
   all <b>Boost.Threads</b> mutex models use an unspecified scheduling policy.</p>
 <h2><a name="concept-requirements"></a>Concept Requirements</h2>
 <h3><a name="Mutex-concept"></a>Mutex 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> 
+<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 
+<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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td><code>M m;</code></td>
     <td>Constructs a mutex object m. Post-condition: m is unlocked.</td>
   </tr>
-  <tr> 
+  <tr>
     <td><code>(&amp;m)-&gt;~M();</code></td>
     <td>Precondition: m is unlocked. Destroys a mutex object m.</td>
   </tr>
-  <tr> 
+  <tr>
     <td><code>M::scoped_lock</code></td>
     <td>A model of <a href="lock_concept.html#ScopedLock">ScopedLock</a>.</td>
   </tr>
 </table>
 <h3><a name="TryMutex-concept"></a>TryMutex Concept</h3>
-<p>A TryMutex is a refinement of <a href="#Mutex-concept">Mutex</a>. For a TryMutex 
-  type M and an object m of that type, the following expressions must be well-formed 
+<p>A TryMutex is a refinement of <a href="#Mutex-concept">Mutex</a>. 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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td><code>M::scoped_try_lock</code></td>
     <td>A model of <a href="lock_concept.html#ScopedTryLock">ScopedTryLock</a>.</td>
   </tr>
 </table>
 <h3><a name="TimedMutex-concept"></a>TimedMutex Concept</h3>
-<p>A TimedMutex is a refinement of <a href="#TryMutex-concept">TryMutex</a>. For 
-  a TimedMutex type M and an object m of that type, the following expressions 
+<p>A TimedMutex is a refinement of <a href="#TryMutex-concept">TryMutex</a>. 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> 
+  <tr>
     <td><b>Expression</b></td>
     <td><b>Effects</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td><code>M::scoped_timed_lock</code></td>
     <td>A model of <a href="lock_concept.html#ScopedTimedLock">ScopedTimedLock</a>.</td>
   </tr>
@@ -197,24 +197,24 @@
 <h2><a name="models"></a>Models</h2>
 <p><b>Boost.Threads</b> currently supplies six models of Mutex.</p>
 <table summary="Mutex concept classes" border="1" cellpadding="5">
-  <tr> 
+  <tr>
     <td><b>Concept</b></td>
     <td><b>Refines</b></td>
     <td><b>Models</b></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><a href="#Mutex-concept">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> 
+  <tr>
     <td valign="top"><a href="#TryMutex-concept">TryMutex</a></td>
     <td valign="top"><a href="#Mutex-concept">Mutex</a></td>
     <td><a href="mutex.html">try_mutex<br>
       </a> <a href="recursive_mutex.html">recursive_try_mutex</a> </td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><a href="#TimedMutex-concept">TimedMutex</a></td>
     <td valign="top"><a href="#TryMutex-concept">TryMutex</a></td>
     <td><a href="mutex.html">timed_mutex<br>
@@ -222,18 +222,18 @@
   </tr>
 </table>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/once.html b/doc/once.html
index efb1b456..e871c6c7 100644
--- a/doc/once.html
+++ b/doc/once.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/once.hpp">boost/thread/once.hpp</a>&gt;</h2>
     </td>
@@ -19,18 +19,18 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#macros">Macros</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#macro-BOOST_ONCE_INIT">BOOST_ONCE_INIT</a></dt>
   </dl>
   <dt><a href="#types">Types</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#type-once_flag">once_flag</a></dt>
   </dl>
   <dt><a href="#functions">Functions</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#function-call_once">call_once</a></dt>
   </dl>
   <dt><a href="#examples">Example(s)</a></dt>
@@ -48,21 +48,21 @@
 <pre>
 <a name="macro-BOOST_ONCE_INIT"></a>#define BOOST_ONCE_INIT <i>implementation defined</i>
 </pre>
-<p>This is a constant value used to initialize <code>once_flag</code> instances 
+<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>
 <h2><a name="types"></a>Types</h2>
 <pre>
 <a name="type-once_flag"></a>typedef <i>implementation defined</i> once_flag;
 </pre>
-<p>This implementation defined type is used as a flag to insure a routine is called 
+<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>BOOST_ONCE_INIT</code>.</p>
 <h2><a name="functions"></a>Functions</h2>
 <pre>
 <a name="function-call_once"></a>void call_once(void (*func)(), once_flag& flag);
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> The function <code>func</code> shall not throw exceptions.</dt>
-  <dt><b>Effects:</b> As if (in an atomic fashion): 
+  <dt><b>Effects:</b> As if (in an atomic fashion):
     <pre>
 if (flag == BOOST_ONCE_INIT)
     func();
@@ -71,46 +71,20 @@ if (flag == BOOST_ONCE_INIT)
   <dt><b>Postconditions:</b> <code>flag != BOOST_ONCE_INIT</code></dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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>
+<p><a href="../example/once.cpp">libs/thread/example/once.cpp</a></p>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/overview.html b/doc/overview.html
index d34029d3..2b78f38f 100644
--- a/doc/overview.html
+++ b/doc/overview.html
@@ -7,115 +7,115 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Overview</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="index"> 
+<dl class="index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#dangers">Dangers</a></dt>
-  <dl class="index"> 
+  <dl class="index">
     <dt><a href="#testing-debugging">Testing and debugging considerations</a></dt>
     <dt><a href="#head-start">Getting a head start</a></dt>
   </dl>
   <dt><a href="#library">C++ Standard Library usage in multithreaded programs</a></dt>
-  <dl class="index"> 
+  <dl class="index">
     <dt><a href="#runtime-libraries">Runtime libraries</a></dt>
     <dt><a href="#non-thread-safe-functions">Potentially non-thread-safe functions</a></dt>
   </dl>
-  <dt><a href="#common-requirements">Common requirements for all Boost.Threads 
+  <dt><a href="#common-requirements">Common requirements for all Boost.Threads
     components</a></dt>
-  <dl class="index"> 
+  <dl class="index">
     <dt><a href="#exceptions">Exceptions</a></dt>
     <dt><a href="#non-copyable">NonCopyable requirement</a></dt>
   </dl>
 </dl>
 <h2><a name="introduction"></a>Introduction</h2>
-<p>Boost.Threads allows C++ programs to execute as multiple, asynchronous, independent, 
-  threads-of-execution. Each thread has its own machine state including program 
-  instruction counter and registers. Programs which execute as multiple threads 
-  are called multithreaded programs to distinguish them from traditional single-threaded 
-  programs. <a href="definitions.html">Definitions</a> gives a more complete description 
+<p>Boost.Threads allows C++ programs to execute as multiple, asynchronous, independent,
+  threads-of-execution. Each thread has its own machine state including program
+  instruction counter and registers. Programs which execute as multiple threads
+  are called multithreaded programs to distinguish them from traditional single-threaded
+  programs. <a href="definitions.html">Definitions</a> gives a more complete description
   of the multithreading execution environment.</p>
 <p>Multithreading provides several advantages:</p>
 <ul>
-  <li>Programs which would otherwise block waiting for some external event can 
-    continue to respond if the blocking operation is placed in a separate thread. 
+  <li>Programs which would otherwise block waiting for some external event can
+    continue to respond if the blocking operation is placed in a separate thread.
     Multithreading is usually an absolute requirement for these programs.</li>
 </ul>
 <ul>
-  <li>Well-designed multithreaded programs may execute faster than single-threaded 
-    programs, particularly on multiprocessor hardware. Note, however, that poorly-designed 
+  <li>Well-designed multithreaded programs may execute faster than single-threaded
+    programs, particularly on multiprocessor hardware. Note, however, that poorly-designed
     multithreaded programs are often slower that single-threaded programs.</li>
 </ul>
 <ul>
-  <li>Some program designs may be easier to formulate using a multithreaded approach. 
+  <li>Some program designs may be easier to formulate using a multithreaded approach.
     After all, the real world is asynchronous!</li>
 </ul>
 <h2><a name="dangers"></a>Dangers</h2>
-<p>Beyond the errors which can occur in single-threaded programs, multithreaded 
+<p>Beyond the errors which can occur in single-threaded programs, multithreaded
   programs are subject to additional errors:</p>
 <ul>
   <li><a href="definitions.html#definition-race-condition">Race conditions</a>.</li>
-  <li><a href="definitions.html#definition-deadlock">Deadlock</a> (sometimes called 
+  <li><a href="definitions.html#definition-deadlock">Deadlock</a> (sometimes called
     &quot;deadly embrace&quot;)</li>
-  <li><a href="definitions.html#definition-priority-failure">Priority failures</a> 
+  <li><a href="definitions.html#definition-priority-failure">Priority failures</a>
     (priority inversion, infinite overtaking, starvation, etc.)</li>
 </ul>
-<p>Every multithreaded program must be designed carefully to avoid race conditions, 
-  priority failures and deadlock. These aren&#39;t rare or exotic failures - they 
-  are virtually guaranteed to occur unless multithreaded code is designed to avoid 
+<p>Every multithreaded program must be designed carefully to avoid race conditions,
+  priority failures and deadlock. These aren&#39;t rare or exotic failures - they
+  are virtually guaranteed to occur unless multithreaded code is designed to avoid
   them. Priority failures are somewhat less common, but are nonetheless serious.</p>
-<p>The <a href="introduction.html">Boost.Threads design</a> attempts to minimize 
-  these errors, but they will still occur unless the programmer proactively designs 
+<p>The <a href="introduction.html">Boost.Threads design</a> attempts to minimize
+  these errors, but they will still occur unless the programmer proactively designs
   to avoid them.</p>
 <h3><a name="testing-debugging"></a>Testing and debugging considerations</h3>
-<p>Multithreaded programs are non-deterministic. In other words, the same program 
-  with the same input data may follow different execution paths each time it is 
+<p>Multithreaded programs are non-deterministic. In other words, the same program
+  with the same input data may follow different execution paths each time it is
   invoked. That can make testing and debugging a nightmare:</p>
 <ul>
   <li>Failures are often not repeatable.</li>
-  <li>Probe effect causes debuggers to produce very different results from non-debug 
+  <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 
+  <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 
+  <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><a name="head-start"></a>Getting a head start</h3>
-<p>Although it might appear that multithreaded programs are inherently unreliable, 
-  many reliable multithreaded programs do exist. Multithreading techniques are 
+<p>Although it might appear that multithreaded programs are inherently unreliable,
+  many reliable multithreaded programs do exist. Multithreading techniques are
   known which lead to reliable programs.</p>
-<p>Design patterns for reliable multithreaded programs, including the important 
-  <i>monitor</i> pattern, are presented in <cite> Pattern-Oriented Software Architecture 
+<p>Design patterns for reliable multithreaded programs, including the important
+  <i>monitor</i> pattern, are presented in <cite> Pattern-Oriented Software Architecture
   Volume 2 - Patterns for Concurrent and Networked Objects</cite> [<a href=
-        "bibliography.html#Schmidt-00">Schmidt 00</a>]. Many important multithreading 
-  programming considerations (independent of threading library) are discussed 
-  in <cite>Programming with POSIX Threads</cite> [<a href="bibliography.html#Butenhof-97">Butenhof 
+        "bibliography.html#Schmidt-00">Schmidt 00</a>]. Many important multithreading
+  programming considerations (independent of threading library) are discussed
+  in <cite>Programming with POSIX Threads</cite> [<a href="bibliography.html#Butenhof-97">Butenhof
   97</a>].</p>
-<p>Doing some reading before attempting multithreaded designs will give you a 
+<p>Doing some reading before attempting multithreaded designs will give you a
   head start toward reliable multithreaded programs.</p>
 <h2><a name="library"></a>C++ Standard Library usage in multithreaded programs</h2>
 <h3><a name="runtime-libraries"></a>Runtime libraries</h3>
-<p><b>Warning:</b> Multithreaded programs such as those using <b> Boost.Threads</b> 
-  must link to <a href="definitions.html#Thread-safe"> thread-safe</a> versions 
-  of all runtime libraries used by the program, including the runtime library 
-  for the C++ Standard Library. Otherwise <a href="definitions.html#Race condition">race 
-  conditions</a> will occur when multiple threads simultaneously execute runtime 
-  library functions for <i>new</i>, <i>delete</i>, or other language features 
+<p><b>Warning:</b> Multithreaded programs such as those using <b> Boost.Threads</b>
+  must link to <a href="definitions.html#Thread-safe"> thread-safe</a> versions
+  of all runtime libraries used by the program, including the runtime library
+  for the C++ Standard Library. Otherwise <a href="definitions.html#Race condition">race
+  conditions</a> will occur when multiple threads simultaneously execute runtime
+  library functions for <i>new</i>, <i>delete</i>, or other language features
   which imply shared state.</p>
 <h3><a name="non-thread-safe-functions"></a>Potentially non-thread-safe functions</h3>
-<p>Certain C++ Standard Library functions inherited from C are particular problems 
+<p>Certain C++ Standard Library functions inherited from C are particular problems
   because they hold internal state between calls:</p>
 <ul>
   <li>rand</li>
@@ -125,49 +125,49 @@
   <li>gmtime</li>
   <li>localtime</li>
 </ul>
-<p>It is possible to write thread-safe implementations of these by using <a href="tss.html#class-thread_specific_ptr">thread-specific 
-  storage</a>, and several C++ compiler vendors do just that. The technique is 
+<p>It is possible to write thread-safe implementations of these by using <a href="tss.html#class-thread_specific_ptr">thread-specific
+  storage</a>, and several C++ compiler vendors do just that. The technique is
   well-know and is explained in [<a href=
         "bibliography.html#Butenhof-97">Buttenhof 97</a>].</p>
-<p>But at least one vendor (HP-UX) does not provide thread-safe implementations 
-  of the above functions in their otherwise thread-safe runtime library. Instead 
+<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 
+<p><b>Recommendation:</b> For the most portable, yet thread-safe code, use Boost
   replacements for the problem functions. See the <a href=
         "../../random/index.html">Boost Random Number Library</a> and <a href=
         "../../tokenizer/index.htm">Boost Tokenizer Library</a>.</p>
 <h2><a name="common-gaurantees"></a>Common guarantees for all Boost.Threads components</h2>
 <h3><a name="exceptions"></a>Exceptions</h3>
-<p><b>Boost.Threads</b> destructors never throw exceptions. Unless otherwise specified, 
-  other <b>Boost.Threads</b> functions that do not have an exception-specification 
+<p><b>Boost.Threads</b> destructors never throw exceptions. Unless otherwise specified,
+  other <b>Boost.Threads</b> functions that do not have an exception-specification
   may throw implementation-defined exceptions.</p>
-<p>In particular, <b>Boost.Threads</b> reports failure to allocate storage by 
-  throwing an exception of type std::bad_alloc, or a class derived from std::bad_alloc, 
-  failure to obtain thread resources other than memory by throwing an exception 
-  of type <a href="exceptions.html#class-thread_resource_error">boost::thread_resource_error</a>, 
+<p>In particular, <b>Boost.Threads</b> reports failure to allocate storage by
+  throwing an exception of type std::bad_alloc, or a class derived from std::bad_alloc,
+  failure to obtain thread resources other than memory by throwing an exception
+  of type <a href="exceptions.html#class-thread_resource_error">boost::thread_resource_error</a>,
   and certain lock related failures by throwing an exception of type <a href="exceptions.html#class-lock_error">boost::lock_error</a></p>
-<p><b>Rationale:</b> Follows the C++ Standard Library practice of allowing all 
-  functions except destructors or other specified functions to throw exceptions 
+<p><b>Rationale:</b> Follows the C++ Standard Library practice of allowing all
+  functions except destructors or other specified functions to throw exceptions
   on errors.</p>
 <h3><a name="non-copyable"></a>NonCopyable requirement</h3>
-<p><b>Boost.Threads</b> classes documented as meeting the NonCopyable requirement 
-  disallow copy construction and copy assignment. For the sake of exposition, 
-  the synopsis of such classes show private derivation from <a href="../../utility/utility.htm"> 
-  boost::noncopyable</a>. Users should not depend on this derivation, however, 
+<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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/rationale.html b/doc/rationale.html
index 1a044f4c..cbb2f4a4 100644
--- a/doc/rationale.html
+++ b/doc/rationale.html
@@ -7,141 +7,141 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Rationale</h2>
     </td>
   </tr>
 </table>
 <hr>
-<dl class="index"> 
+<dl class="index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#library">Rationale for the Creation of <b>Boost.Threads</b></a></dt>
-  <dt><a href="#primitives">Rationale for the Low Level Primitives Supported in 
+  <dt><a href="#primitives">Rationale for the Low Level Primitives Supported in
     <b>Boost.Threads</b></a></dt>
   <dt><a href="#lock_objects">Rationale for the Lock Design</a></dt>
   <dt><a href="#non-copyable">Rationale for NonCopyable Thread Type</a></dt>
   <dt><a href="#events">Rationale for not providing <i>Event Variables</i></a></dt>
 </dl>
 <h2><a name="introduction"></a>Introduction</h2>
-<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 
+<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"></a>Rationale for the Creation of <b>Boost.Threads</b></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 
-  multithreaded programming are quite well known to most modern programmers, yet 
+<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
+  multithreaded 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 multithreaded 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 
+<p>Many platforms support multithreaded 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 
+<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 
+<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 <b>Boost.Threads</b> library was developed to provide a C++ developer with 
-  a portable interface for writing multithreaded programs on numerous platforms. 
-  There&#39;s a hope that the library can be the basis for a more detailed proposal 
+<p>The <b>Boost.Threads</b> library was developed to provide a C++ developer with
+  a portable interface for writing multithreaded 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"></a>Rationale for the Low Level Primitives Supported 
+<h2><a name="primitives"></a>Rationale for the Low Level Primitives Supported
   in <b>Boost.Threads</b></h2>
-<p>The <b>Boost.Threads</b> library supplies a set of low level primitives for 
-  writing multithreaded programs, such as mutexes and condition variables. In 
-  fact, the first release of <b>Boost.Threads</b> 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&#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 <b>Boost.Threads</b> 
+<p>The <b>Boost.Threads</b> library supplies a set of low level primitives for
+  writing multithreaded programs, such as mutexes and condition variables. In
+  fact, the first release of <b>Boost.Threads</b> 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&#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 <b>Boost.Threads</b>
   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 
+<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 multithreaded 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 
+<p>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&#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"></a>Rationale for the Lock Design</h2>
-<p>Programmers who are used to multithreaded 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 multithreading primitive that&#39;s not thread-safe 
+<p>Programmers who are used to multithreaded 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 multithreading 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 (in fact, to do so would likely be an error). Nor are there any cases 
+<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 (in fact, to do so would likely be an error). 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 
+<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 <b>Boost.Threads</b> 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 
+<p>So, to avoid the overhead of synchronizing access to the state information
+  and to avoid the race condition the <b>Boost.Threads</b> 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 multithreading issues.</p>
 <h2><a name="non-copyable"></a>Rationale for NonCopyable Thread Type</h2>
-<p>Programmers who are used to C libraries for multithreaded programming are likely 
-  to wonder why <b>Boost.Threads</b> uses a noncopyable 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 
+<p>Programmers who are used to C libraries for multithreaded programming are likely
+  to wonder why <b>Boost.Threads</b> uses a noncopyable 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 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&#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 
+<p>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&#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 
+<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 than wrappers (such as boost::shared_ptr) around a noncopyable 
-  thread concept. Analysis of whether or not these arguments would hold true doesn&#39;t 
-  appear to bear them out. To illustrate the analysis we&#39;ll first provide 
+<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 than wrappers (such as boost::shared_ptr) around a noncopyable
+  thread concept. Analysis of whether or not these arguments would hold true doesn&#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>
@@ -193,22 +193,22 @@ Void foo()
    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 
+<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 
+<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. 
+<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 
+<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>
@@ -232,7 +232,7 @@ void foo()
 
 void foo()
 {
-   thread_ref thrd = 
+   thread_ref thrd =
    create_thread(&amp;bar);thrd-&gt;join();
 }
 </pre>
@@ -267,7 +267,7 @@ 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]-&gt;join();    
+      ++i)threads[i]-&gt;join();
 }
 </pre>
 <h3>5.</h3>
@@ -300,13 +300,13 @@ void foo()
    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 
+<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()
@@ -318,82 +318,82 @@ void foo()
 }
 </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 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 (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 
+<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 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 (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 <b>Boost.Threads</b> 
+<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 <b>Boost.Threads</b>
   library has gone with a noncopyable design.</p>
 <h2><a name="events"></a>Rationale for not providing <i>Event 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, 
+<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 
+<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 
+<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 
+<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 
+<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 
+<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 
+        "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 <b>Boost.Threads</b> 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, 
+<p>The decision to exclude event variables from <b>Boost.Threads</b> 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 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/recursive_mutex.html b/doc/recursive_mutex.html
index 86ac9493..9371509e 100644
--- a/doc/recursive_mutex.html
+++ b/doc/recursive_mutex.html
@@ -7,40 +7,40 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/recursive_mutex.hpp">boost/thread/recursive_mutex.hpp</a>&gt;</h2>    </td>
   </tr>
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-recursive_mutex">Class <code>recursive_mutex</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-recursive_mutex-synopsis">Class <code>recursive_mutex</code> 
+    <dl class="page-index">
+      <dt><a href="#class-recursive_mutex-synopsis">Class <code>recursive_mutex</code>
         synopsis</a></dt>
-      <dt><a href="#class-recursive_mutex-ctors">Class <code>recursive_mutex</code> 
+      <dt><a href="#class-recursive_mutex-ctors">Class <code>recursive_mutex</code>
         constructors and destructor</a></dt>
     </dl>
     <dt><a href="#class-recursive_try_mutex">Class <code>recursive_try_mutex</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-recursive_try_mutex-synopsis">Class <code>recursive_try_mutex</code> 
+    <dl class="page-index">
+      <dt><a href="#class-recursive_try_mutex-synopsis">Class <code>recursive_try_mutex</code>
         synopsis</a></dt>
-      <dt><a href="#class-recursive_try_mutex-ctors">Class <code>recursive_try_mutex</code> 
+      <dt><a href="#class-recursive_try_mutex-ctors">Class <code>recursive_try_mutex</code>
         constructors and destructor</a></dt>
     </dl>
     <dt><a href="#class-recursive_timed_mutex">Class <code>recursive_timed_mutex</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-recursive_timed_mutex-synopsis">Class <code>recursive_timed_mutex</code> 
+    <dl class="page-index">
+      <dt><a href="#class-recursive_timed_mutex-synopsis">Class <code>recursive_timed_mutex</code>
         synopsis</a></dt>
-      <dt><a href="#class-recursive_timed_mutex-ctors">Class <code>recursive_timed_mutex</code> 
+      <dt><a href="#class-recursive_timed_mutex-ctors">Class <code>recursive_timed_mutex</code>
         constructors and destructor</a></dt>
     </dl>
   </dl>
@@ -65,26 +65,26 @@
   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> 
+  <tr>
     <td><b>Mutex Class</b></td>
     <td><b>Lock name</b></td>
     <td><b>Lock Concept</b></td>
   </tr>
-  <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="lock_concept.html#ScopedLock"> ScopedLock</a></td>
   </tr>
-  <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="lock_concept.html#ScopedLock"> ScopedLock</a><br>
       <a href="lock_concept.html#ScopedTryLock"> ScopedTryLock</a></td>
   </tr>
-  <tr> 
+  <tr>
     <td valign="top"><code><a href=
-                "#recursive_timed_mutex Synopsis"> recursive_timed_mutex</a></code> 
+                "#recursive_timed_mutex Synopsis"> recursive_timed_mutex</a></code>
     </td>
     <td valign="middle"><code>scoped_lock<br>
       scoped_try_lock<br>
@@ -94,23 +94,23 @@
       <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 
+<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 <b>undefined behavior</b>.</p>
-<p>The <code>recursive_mutex</code>, <code>recursive_try_mutex</code> and <code>recursive_timed_mutex</code> 
+<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 
+        "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="classes"></a>Classes</h2>
 <h3><a name="class-recursive_mutex"></a>Class <code>recursive_mutex</code></h3>
-<p>The <code>recursive_mutex</code> class is a model of <a href="mutex_concept.html#Mutex-concept">Mutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>recursive_mutex</code> class is a model of <a href="mutex_concept.html#Mutex-concept">Mutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
-<h4><a name="class-recursive_mutex-synopsis"></a>Class <code>recursive_mutex</code> 
+<h4><a name="class-recursive_mutex-synopsis"></a>Class <code>recursive_mutex</code>
   synopsis</h4>
 <pre>
 namespace boost
@@ -120,33 +120,33 @@ namespace boost
     {
     public:
         typedef [implementation defined; see Introduction] scoped_lock;
-        
+
         recursive_mutex();
         ~recursive_mutex();
     };
 };
 </pre>
-<h4><a name="class-recursive_mutex-ctors"></a>Class <code>recursive_mutex</code> 
+<h4><a name="class-recursive_mutex-ctors"></a>Class <code>recursive_mutex</code>
   constructors and destructor</h4>
 <pre>
 recursive_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~recursive_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h3><a name="class-recursive_try_mutex"></a>Class <code>recursive_try_mutex</code></h3>
-<p>The <code>recursive_try_mutex</code> class is a model of <a href="mutex_concept.html#TryMutex-concept">TryMutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>recursive_try_mutex</code> class is a model of <a href="mutex_concept.html#TryMutex-concept">TryMutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
-<h4><a name="class-recursive_try_mutex-synopsis"></a>Class <code>recursive_try_mutex</code> 
+<h4><a name="class-recursive_try_mutex-synopsis"></a>Class <code>recursive_try_mutex</code>
   synopsis</h4>
 <pre>
 namespace boost
@@ -157,33 +157,33 @@ namespace boost
     Public:
         typedef [implementation defined; see Introduction] scoped_lock;
         typedef [implementation defined; see Introduction] scoped_try_lock;
-        
+
         recursive_try_mutex();
         ~recursive_try_mutex();
     };
 };
 </pre>
-<h4><a name="class-recursive_try_mutex-ctors"></a>Class <code>recursive_try_mutex</code> 
+<h4><a name="class-recursive_try_mutex-ctors"></a>Class <code>recursive_try_mutex</code>
   constructors and destructor</h4>
 <pre>
 recursive_try_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~recursive_try_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h3><a name="class-recursive_timed_mutex"></a>Class <code>recursive_timed_mutex</code></h3>
-<p>The <code>recursive_timed_mutex</code> class is a model of <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a> 
-  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional 
+<p>The <code>recursive_timed_mutex</code> class is a model of <a href="mutex_concept.html#TimedMutex-concept">TimedMutex</a>
+  and <a href="overview.html#non-copyable">NonCopyable</a>, and provides no additional
   facilities beyond the requirements of these concepts.</p>
-<h4><a name="class-recursive_timed_mutex-synopsis"></a>Class <code>recursive_timed_mutex</code> 
+<h4><a name="class-recursive_timed_mutex-synopsis"></a>Class <code>recursive_timed_mutex</code>
   synopsis</h4>
 <pre>
 namespace boost
@@ -195,74 +195,30 @@ namespace boost
         typedef [implementation defined; see Introduction] scoped_lock;
         typedef [implementation defined; see Introduction] scoped_try_lock;
         typedef [implementation defined; see Introduction] scoped_timed_lock;
-        
+
         recursive_timed_mutex();
         ~recursive_timed_mutex();
     };
 };
 </pre>
-<h4><a name="class-recursive_timed_mutex-ctors"></a>Class <code>recursive_timed_mutex</code> 
+<h4><a name="class-recursive_timed_mutex-ctors"></a>Class <code>recursive_timed_mutex</code>
   constructors and destructor</h4>
 <pre>
 recursive_timed_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Postconditions:</b> <code>*this</code> is in an unlocked state.</dt>
 </dl>
 <pre>
 ~recursive_timed_mutex();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is in an unlocked sate.</dt>
-  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error 
+  <dt><b>Danger:</b> Destruction of a locked mutex is a serious programming error
     resulting in undefined behavior such as a program crash.</dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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><a href="../example/recursive_mutex.cpp">libs/thread/example/recursive_mutex.cpp</a></p>
 <p>The output is:</p>
 <pre>
 count == 1
@@ -271,18 +227,18 @@ count == 3
 count == 4
 </pre>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/thread.html b/doc/thread.html
index 7f88de47..c8885c16 100644
--- a/doc/thread.html
+++ b/doc/thread.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/thread.hpp">boost/thread.hpp</a>&gt;</h2>
     </td>
@@ -19,33 +19,33 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-thread">Class <code>thread</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-thread-synopsis">Class <code>thread</code> synopsis</a></dt>
-      <dt><a href="#class-thread-ctors">Class <code>thread</code> constructors 
+      <dt><a href="#class-thread-ctors">Class <code>thread</code> constructors
         and destructor</a></dt>
-      <dt><a href="#class-thread-comparisons">Class <code>thread</code> comparison 
+      <dt><a href="#class-thread-comparisons">Class <code>thread</code> comparison
         functions</a></dt>
-      <dt><a href="#class-thread-modifiers">Class <code>thread</code> modifier 
+      <dt><a href="#class-thread-modifiers">Class <code>thread</code> modifier
         functions</a></dt>
       <dt><a href="#class-thread-statics">Class <code>thread</code> static functions</a></dt>
     </dl>
     <dt><a href="#class-thread_group">Class <code>thread_group</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-thread_group-synopsis">Class <code>thread_group</code> 
+    <dl class="page-index">
+      <dt><a href="#class-thread_group-synopsis">Class <code>thread_group</code>
         synopsis</a></dt>
-      <dt><a href="#class-thread_group-ctors">Class <code>thread_group</code> 
+      <dt><a href="#class-thread_group-ctors">Class <code>thread_group</code>
         constructors and destructor</a></dt>
-      <dt><a href="#class-thread_group-modifiers">Class <code>thread_group</code> 
+      <dt><a href="#class-thread_group-modifiers">Class <code>thread_group</code>
         modifier functions</a></dt>
     </dl>
   </dl>
   <dt><a href="#examples">Example(s)</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#example-thread">Simple usage of <code>boost::thread</code></a></dt>
     <dt><a href="#example-thread_group">Simple usage of <code>boost::thread_group</code></a></dt>
   </dl>
@@ -57,32 +57,32 @@
   which are used to create, observe and manage threads and groups of threads.</p>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-thread"></a>Class <code>thread</code></h3>
-<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 
+<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 
+<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) 
+<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; 
+<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> 
+<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 
+<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>
 <h4><a name="class-thread-synopsis"></a>Class <code>thread</code> synopsis</h4>
 <pre>
@@ -107,13 +107,13 @@ public:
 };
 } // namespace boost
 </pre>
-<h4><a name="class-thread-ctors"></a>Class <code>thread</code> constructors and 
+<h4><a name="class-thread-ctors"></a>Class <code>thread</code> constructors and
   destructor</h4>
 <pre>
 thread();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> Constructs a <code>thread</code> object representing the 
+<dl class="function-semantics">
+  <dt><b>Effects:</b> Constructs a <code>thread</code> object representing the
     current thread of execution.</dt>
   <dt><b>Postconditions:</b> <code>*this</code> is non-joinable.</dt>
   <dt><b>Danger:</b> <code>*this</code> is valid only within the current thread.</dt>
@@ -121,43 +121,43 @@ thread();
 <pre>
 thread(const <a href="../../function/index.html">boost::function0</a>&lt;void&gt;&amp; threadfunc);
 </pre>
-<dl class="function-semantics"> 
-  <dt><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 
+<dl class="function-semantics">
+  <dt><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.</dt>
   <dt><b>Postconditions:</b> <code>*this</code> is joinable.</dt>
-  <dt><b>Throws:</b> <code>boost::thread_resource_error</code> if a new thread 
+  <dt><b>Throws:</b> <code>boost::thread_resource_error</code> if a new thread
     of execution cannot be started.</dt>
 </dl>
 <pre>
 ~Thread();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> Destroys <code>*this</code>. The actual thread of execution 
+<dl class="function-semantics">
+  <dt><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.</dt>
-  <dt><b>Note:</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 
+  <dt><b>Note:</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>.</dt>
 </dl>
-<h4><a name="class-thread-comparisons"></a>Class <code>thread</code> comparison 
+<h4><a name="class-thread-comparisons"></a>Class <code>thread</code> comparison
   functions</h4>
 <pre>
 bool operator==(const thread&amp; rhs) const;
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> The thread is non-terminated or <code>*this</code> is joinable.</dt>
-  <dt><b>Returns:</b> <code>true</code> if <code>*this</code> and <code> rhs</code> 
+  <dt><b>Returns:</b> <code>true</code> if <code>*this</code> and <code> rhs</code>
     represent the same thread of execution.</dt>
 </dl>
 <pre>
 bool operator!=(const thread&amp; rhs) const;
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> The thread is non-terminated or <code>*this</code> is joinable.</dt>
   <dt><b>Returns:</b> <code>!(*this==rhs)</code>.</dt>
 </dl>
@@ -165,40 +165,40 @@ bool operator!=(const thread&amp; rhs) const;
 <pre>
 void join();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> <code>*this</code> is joinable.</dt>
-  <dt><b>Effects:</b> The current thread of execution blocks until the initial 
-    function of the thread of execution represented by <code> *this</code> finishes 
+  <dt><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.</dt>
   <dt><b>Postconditions:</b> <code>*this</code> is non-joinable.</dt>
-  <dt><b>Notes:</b> If <code>*this == thread()</code> the result is implementation 
-    defined. If the implementation doesn&#39;t detect this the result will be 
+  <dt><b>Notes:</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>.</dt>
 </dl>
 <h4><a name="class-thread-statics"></a>Class <code>thread</code> static functions</h4>
 <pre>
 static void sleep(const <a href="xtime.html">xtime</a>&amp; XT);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> The current thread of execution blocks until <code> XT</code> 
+<dl class="function-semantics">
+  <dt><b>Effects:</b> The current thread of execution blocks until <code> XT</code>
     is reached.</dt>
 </dl>
 <pre>
 static void yield();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> The current thread of execution is placed in the &quot;ready&quot; 
+<dl class="function-semantics">
+  <dt><b>Effects:</b> The current thread of execution is placed in the &quot;ready&quot;
     state.</dt>
-  <dt><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 
+  <dt><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.</dt>
 </dl>
 <h3><a name="class-thread_group"></a>Class <code>thread_group</code></h3>
-<p>The <tt>thread_group</tt> class provides a container for easy grouping of threads 
+<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>
-<h4><a name="class-thread_group-synopsis"></a>Class <code>thread_group</code> 
+<h4><a name="class-thread_group-synopsis"></a>Class <code>thread_group</code>
   synopsis</h4>
 <pre>
 namespace boost {
@@ -216,62 +216,62 @@ namespace boost {
     };
 } // namespace boost
 </pre>
-<h4><a name="class-thread_group-ctors"></a>Class <code>thread_group</code> constructors 
+<h4><a name="class-thread_group-ctors"></a>Class <code>thread_group</code> constructors
   and destructor</h4>
 <pre>
 thread_group();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Constructs an empty <code>thread_group</code> container.</dt>
 </dl>
 <pre>
 ~thread_group();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Effects:</b> Destroys each contained thread object. Destroys <code>*this</code>.</dt>
-  <dt><b>Notes:</b> Behavior is undefined if another thread references *this during 
+  <dt><b>Notes:</b> Behavior is undefined if another thread references *this during
     the execution of the destructor.</dt>
 </dl>
-<h4><a name="class-thread_group-modifiers"></a>Class <code>thread_group</code> 
+<h4><a name="class-thread_group-modifiers"></a>Class <code>thread_group</code>
   modifier functions</h4>
 <pre>
 thread* create_thread(const boost::function0&lt;void&gt;&amp; threadfunc);
 </pre>
-<dl class="function-semantics"> 
-  <dt><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 
+<dl class="function-semantics">
+  <dt><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.</dt>
   <dt><b>Returns:</b> Pointer to the newly created thread.</dt>
 </dl>
 <pre>
 void add_thread(thread* thrd);
 </pre>
-<dl class="function-semantics"> 
-  <dt><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 
+<dl class="function-semantics">
+  <dt><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.</dt>
 </dl>
 <pre>
 Void remove_thread(thread* thrd);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> Removes <code>*this</code>&#39;s list of managed <tt>thread</tt> 
+<dl class="function-semantics">
+  <dt><b>Effects:</b> Removes <code>*this</code>&#39;s list of managed <tt>thread</tt>
     objects.</dt>
-  <dt><b>Throws:</b> ? if <tt>thrd</tt> is not it <code>*this</code>&#39;s list 
+  <dt><b>Throws:</b> ? if <tt>thrd</tt> is not it <code>*this</code>&#39;s list
     of managed <tt>thread</tt> objects.</dt>
 </dl>
 <pre>
 Void join_all();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Effects:</b> Calls <code>join()</code> on each of the managed <tt>thread</tt> 
+<dl class="function-semantics">
+  <dt><b>Effects:</b> Calls <code>join()</code> on each of the managed <tt>thread</tt>
     objects.</dt>
 </dl>
 <h2><a name="functions"></a>Functions</h2>
 <pre>
 <a name="function-spec"></a>{{function}}
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> {{text}}</dt>
   <dt><b>Effects:</b> {{text}}</dt>
   <dt><b>Postconditions:</b> {{text}}</dt>
@@ -284,63 +284,14 @@ Void join_all();
 <p><a name="object-spec"></a>{{Object specifications}}</p>
 <h2><a name="examples"></a>Example(s)</h2>
 <h3><a name="example-thread"></a>Simple usage of <code>boost::thread</code></h3>
-<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><a href="../example/thread.cpp">libs/thread/example/thread.cpp</a></p>
 <p>The output is:</p>
 <pre>
 setting alarm for 5 seconds...
 alarm sounded...
 </pre>
 <h3><a name="example-thread_group"></a>Simple usage of <code>boost::thread_group</code></h3>
-<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><a href="../example/thread_group.cpp">libs/thread/example/thread_group.cpp</a></p>
 <p>The output is:</p>
 <pre>
 count = 1
@@ -355,18 +306,18 @@ count = 9
 count = 10
 </pre>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/tss.html b/doc/tss.html
index 0028733e..0cde83cf 100644
--- a/doc/tss.html
+++ b/doc/tss.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/tss.hpp">boost/thread/tss.hpp</a>&gt;</h2>
     </td>
@@ -19,19 +19,19 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-thread_specific_ptr">Class <code>thread_specific_ptr</code></a></dt>
-    <dl class="page-index"> 
-      <dt><a href="#class-thread_specific_ptr-synopsis">Class <code>thread_specific_ptr</code> 
+    <dl class="page-index">
+      <dt><a href="#class-thread_specific_ptr-synopsis">Class <code>thread_specific_ptr</code>
         synopsis</a></dt>
-      <dt><a href="#class-thread_specific_ptr-ctors">Class <code>thread_specific_ptr</code> 
+      <dt><a href="#class-thread_specific_ptr-ctors">Class <code>thread_specific_ptr</code>
         constructors and destructor</a></dt>
-      <dt><a href="#class-thread_specific_ptr-modifiers">Class <code>thread_specific_ptr</code> 
+      <dt><a href="#class-thread_specific_ptr-modifiers">Class <code>thread_specific_ptr</code>
         modifier functions</a></dt>
-      <dt><a href="#class-thread_specific_ptr-observers">Class <code>thread_specific_ptr</code> 
+      <dt><a href="#class-thread_specific_ptr-observers">Class <code>thread_specific_ptr</code>
         observer functions</a></dt>
     </dl>
   </dl>
@@ -44,9 +44,9 @@
   which is used to manage data associated with specific thread instances.</p>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-thread_specific_ptr"></a>Class <code>thread_specific_ptr</code></h3>
-<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> 
+<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 a specified cleanup 
@@ -57,13 +57,13 @@
   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 originally written assuming a single thread of control 
+  <li>An interface was originally written assuming a single thread of control
     and is being ported to a multithreaded 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 
+  <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>
-<h4><a name="class-thread_specific_ptr-synopsis"></a>Class <code>thread_specific_ptr</code> 
+<h4><a name="class-thread_specific_ptr-synopsis"></a>Class <code>thread_specific_ptr</code>
   synopsis</h4>
 <pre>
 namespace boost
@@ -84,12 +84,12 @@ namespace boost
     };
 };
 </pre>
-<h4><a name="class-thread_specific_ptr-ctors"></a>Class <code>thread_specific_ptr</code> 
+<h4><a name="class-thread_specific_ptr-ctors"></a>Class <code>thread_specific_ptr</code>
   constructors and destructor</h4>
 <pre>
 thread_specific_ptr();
 </pre>
-<dl class="function-semantics"> 
+<dl class="function-semantics">
   <dt><b>Requires:</b> The expression <code>delete get()</code> is well formed.</dt>
   <dt><b>Effects:</b> A thread-specific data key is allocated and visible to all 
     threads in the process. Upon creation, the value <code>NULL</code> will be 
@@ -158,13 +158,13 @@ thread_specific_ptr(void (*cleanup)(void*));
     another thread's execution path, making it impossible to call the cleanup 
     methods safely.</dt>
 </dl>
-<h4><a name="class-thread_specific_ptr-modifiers"></a>Class <code>thread_specific_ptr</code> 
+<h4><a name="class-thread_specific_ptr-modifiers"></a>Class <code>thread_specific_ptr</code>
   modifier functions</h4>
 <pre>
 T* release();
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Postconditions:</b> <code>*this</code> holds the null pointer for the 
+<dl class="function-semantics">
+  <dt><b>Postconditions:</b> <code>*this</code> holds the null pointer for the
     current thread.</dt>
   <dt><b>Returns:</b> <code>this-&gt;get()</code> prior to the call.</dt>
   <dt><b>Rationale:</b> This method provides a mechanism for the user to relinquish 
@@ -179,13 +179,13 @@ void reset(T* p=0);
   <dt><b>Postconditions:</b> <code>*this</code> holds the pointer <code> p</code> 
     for the current thread.</dt>
 </dl>
-<h4><a name="class-thread_specific_ptr-observers"></a>Class <code>thread_specific_ptr</code> 
+<h4><a name="class-thread_specific_ptr-observers"></a>Class <code>thread_specific_ptr</code>
   observer functions</h4>
 <pre>
 T* get() const;
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Returns:</b> The object stored in thread specific storage for the current 
+<dl class="function-semantics">
+  <dt><b>Returns:</b> The object stored in thread specific storage for the current
     thread for <code>*this</code>.</dt>
   <dt><b>Note:</b> Each thread initially returns 0.</dt>
 </dl>
@@ -203,51 +203,20 @@ T& operator*() const;
   <dt><b>Returns:</b> <code>this-&gt;get()</code>.</dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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>
+<p><a href="../example/tss.cpp">libs/thread/example/tss.cpp</a></p>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/doc/xtime.html b/doc/xtime.html
index bbd68a52..3e8253ab 100644
--- a/doc/xtime.html
+++ b/doc/xtime.html
@@ -7,11 +7,11 @@
 <body link="#0000ff" vlink="#800080">
 <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
     "header">
-  <tr> 
-    <td valign="top" width="300"> 
+  <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"> 
+    <td valign="top">
       <h1 align="center">Boost.Threads</h1>
       <h2 align="center">Header &lt;<a href="../../../boost/thread/xtime.hpp">boost/thread/xtime.hpp</a>&gt;</h2>
     </td>
@@ -19,21 +19,21 @@
 </table>
 <hr>
 <h2>Contents</h2>
-<dl class="page-index"> 
+<dl class="page-index">
   <dt><a href="#introduction">Introduction</a></dt>
   <dt><a href="#values">Values</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#value-spec">TIME_UTC</a></dt>
   </dl>
   <dt><a href="#classes">Classes</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#class-spec">Struct <code>xtime</code></a></dt>
-    <dl class="page-index"> 
+    <dl class="page-index">
       <dt><a href="#class-xtime-synopsis">Struct <code>xtime</code> synopsis</a></dt>
     </dl>
   </dl>
   <dt><a href="#functions">Functions</a></dt>
-  <dl class="page-index"> 
+  <dl class="page-index">
     <dt><a href="#function-xtime_get"><code>xtime_get</code></a></dt>
   </dl>
   <dt><a href="#examples">Example(s)</a></dt>
@@ -51,15 +51,15 @@ enum
     TIME_UTC
 }
 </pre>
-<p>The clock type for Coordinated Universal Time (UTC). The epoch for this clock 
+<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>
 <h2><a name="classes"></a>Classes</h2>
 <h3><a name="class-xtime"></a>Struct <code>xtime</code></h3>
-<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 (or some other time 
-  library) will be provided in Boost as a separate library, at which time <b>Boost.Threads</b> 
+<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 (or some other time
+  library) will be provided in Boost as a separate library, at which time <b>Boost.Threads</b>
   will deprecate its implementation.</p>
 <h4><a name="class-xtime-synopsis"></a>Struct <code>xtime</code> synopsis</h4>
 <pre>
@@ -80,42 +80,31 @@ namespace boost
 <pre>
 <a name="function-xtime_get"></a>int xtime_get(struct xtime* xtp, int clock_type);
 </pre>
-<dl class="function-semantics"> 
-  <dt><b>Postconditions:</b> <code>xtp</code> represents the current point in 
+<dl class="function-semantics">
+  <dt><b>Postconditions:</b> <code>xtp</code> represents the current point in
     time as a duration since the epoch specified by the <code> clock_type</code>.</dt>
   <dt><b>Returns:</b> <code>clock_type</code> if successful, otherwise 0.</dt>
-  <dt><b>Note:</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 
+  <dt><b>Note:</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.</dt>
 </dl>
 <h2><a name="examples"></a>Example(s)</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>
+<p><a href="../example/xtime.cpp">libs/thread/example/xtime.cpp</a></p>
 <hr>
-<p>Revised 
+<p>Revised
   <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
-  05 November, 2001 
+  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> 2001-2002. 
+<p><i>&copy; Copyright <a href="mailto:wekempf@cox.net">William E. Kempf</a> 2001-2002.
   All Rights Reserved.</i></p>
-<p>Permission to use, copy, modify, distribute and sell this software and its 
-  documentation for any purpose is hereby granted without fee, provided that the 
-  above copyright notice appear in all copies and that both that copyright notice 
-  and this permission notice appear in supporting documentation. William E. Kempf 
-  makes no representations about the suitability of this software for any purpose. 
+<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>
diff --git a/example/Jamfile b/example/Jamfile
index eca3fb6a..924dac6d 100644
--- a/example/Jamfile
+++ b/example/Jamfile
@@ -2,22 +2,6 @@
 #  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.
-#
-# Boost.Threads build and test Jamfile
-#
-# Declares the following targets:
-#   1. monitor, an example program.
-#   2. starvephil, an example program.
-#   3. tennis, an example program.
-# 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.
 subproject libs/thread/example ;
@@ -28,41 +12,23 @@ subproject libs/thread/example ;
 SEARCH on <module@>threads.jam = $(BOOST_ROOT)/libs/thread/build ;
 include <module@>threads.jam ;
 
-#######################
-# Declare the Boost.Threads example program monitor.
-
-exe monitor
-    : monitor/monitor.cpp
-      <lib>../build/boost_thread
-      $(threadmon)
-    : <include>$(BOOST_ROOT)
-      $(pthreads-win32)
-      <threading>multi
-    : debug release <runtime-link>static/dynamic
+template example
+    ## sources ##
+    : <template>thread_base <lib>../build/boost_thread <lib>../../test/build/unit_test_framework $(threadmon)
+    ## requirements ##
+    :
+    ## default build ##
+    : release <runtime-link>static
 ;
 
-#######################
-# Declare the Boost.Threads example program starvephil.
-
-exe starvephil
-    : starvephil/starvephil.cpp
-      <lib>../build/boost_thread
-      $(threadmon)
-    : <include>$(BOOST_ROOT)
-      $(pthreads-win32)
-      <threading>multi
-    : debug release <runtime-link>static/dynamic
-;
-
-#######################
-# Declare the Boost.Threads example program tennis.
-
-exe tennis
-    : tennis/tennis.cpp
-      <lib>../build/boost_thread
-      $(threadmon)
-    : <include>$(BOOST_ROOT)
-      $(pthreads-win32)
-      <threading>multi
-    : debug release <runtime-link>static/dynamic
-;
+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 ;
diff --git a/include/boost/thread/condition.hpp b/include/boost/thread/condition.hpp
index a82275ff..8d5d6990 100644
--- a/include/boost/thread/condition.hpp
+++ b/include/boost/thread/condition.hpp
@@ -91,7 +91,7 @@ private:
         enter_wait();
 #endif
 
-        typedef typename detail::thread::lock_ops<M> lock_ops;
+        typedef detail::thread::lock_ops<M> lock_ops;
         typename lock_ops::lock_state state;
         lock_ops::unlock(mutex, state);
 
@@ -111,7 +111,7 @@ private:
         enter_wait();
 #endif
 
-        typedef typename detail::thread::lock_ops<M> lock_ops;
+        typedef detail::thread::lock_ops<M> lock_ops;
         typename lock_ops::lock_state state;
         lock_ops::unlock(mutex, state);
 
diff --git a/include/boost/thread/once.hpp b/include/boost/thread/once.hpp
index 43835422..05449f22 100644
--- a/include/boost/thread/once.hpp
+++ b/include/boost/thread/once.hpp
@@ -30,8 +30,8 @@ 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
 
diff --git a/include/boost/thread/xtime.hpp b/include/boost/thread/xtime.hpp
index e5d84d36..b66d4f2d 100644
--- a/include/boost/thread/xtime.hpp
+++ b/include/boost/thread/xtime.hpp
@@ -40,6 +40,13 @@ struct xtime
 };
 
 int 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
 
diff --git a/src/condition.cpp b/src/condition.cpp
index eec2c145..9099f47e 100644
--- a/src/condition.cpp
+++ b/src/condition.cpp
@@ -244,14 +244,28 @@ void condition::do_wait()
 
 bool condition::do_timed_wait(const xtime& xt)
 {
-    int milliseconds;
-    to_duration(xt, milliseconds);
-
+    bool ret = false;
     unsigned int res = 0;
-    res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_queue), milliseconds);
-    assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
 
-    bool ret = (res == WAIT_OBJECT_0);
+    for (;;)
+    {
+        int milliseconds;
+        to_duration(xt, milliseconds);
+
+        res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_queue), milliseconds);
+        assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
+        ret = (res == WAIT_OBJECT_0);
+
+        if (res == WAIT_TIMEOUT)
+        {
+            xtime cur;
+            xtime_get(&cur, TIME_UTC);
+            if (xtime_cmp(xt, cur) > 0)
+                continue;
+        }
+
+        break;
+    }
 
     unsigned was_waiting=0;
     unsigned was_gone=0;
diff --git a/src/mac/safe.cpp b/src/mac/safe.cpp
index 32260354..cc858a81 100644
--- a/src/mac/safe.cpp
+++ b/src/mac/safe.cpp
@@ -72,7 +72,7 @@ OSStatus safe_enter_critical_region(MPCriticalRegionID pCriticalRegionID, Durati
             if(lDuration != kDurationImmediate && lDuration != kDurationForever)
             {
                 sExpiration = AddDurationToAbsolute(lDuration, UpTime());
-            }            
+            }
             lStatus = MPEnterCriticalRegion(pCriticalRegionCriticalRegionID, lDuration);
             assert(lStatus == noErr || lStatus == kMPTimeoutErr);
             if(lStatus == noErr)
@@ -92,7 +92,7 @@ OSStatus safe_enter_critical_region(MPCriticalRegionID pCriticalRegionID, Durati
                     // no time left
                         lDuration = kDurationImmediate;
                     }
-                }            
+                }
             // if we entered the critical region, exit it again
                 lStatus = MPExitCriticalRegion(pCriticalRegionCriticalRegionID);
                 assert(lStatus == noErr);
diff --git a/src/mutex.cpp b/src/mutex.cpp
index 4999a84c..f1cb21bb 100644
--- a/src/mutex.cpp
+++ b/src/mutex.cpp
@@ -145,12 +145,25 @@ bool timed_mutex::do_trylock()
 
 bool timed_mutex::do_timedlock(const xtime& xt)
 {
-    int milliseconds;
-    to_duration(xt, milliseconds);
+    unsigned int res = 0;
+    for (;;)
+    {
+        int milliseconds;
+        to_duration(xt, milliseconds);
 
-    unsigned int res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), milliseconds);
-    assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
-    return res == WAIT_OBJECT_0;
+        res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), milliseconds);
+        assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
+
+        if (res == WAIT_TIMEOUT)
+        {
+            xtime cur;
+            xtime_get(&cur, TIME_UTC);
+            if (xtime_cmp(xt, cur) > 0)
+                continue;
+        }
+
+        return res == WAIT_OBJECT_0;
+    }
 }
 
 void timed_mutex::do_unlock()
diff --git a/src/once.cpp b/src/once.cpp
index 9139fa56..cdfcebf6 100644
--- a/src/once.cpp
+++ b/src/once.cpp
@@ -59,17 +59,51 @@ static void do_once()
 
 }
 #elif defined(BOOST_HAS_MPTASKS)
-void *remote_call_proxy(void *pData)
-{
-    std::pair<void (*)(), boost::once_flag *> &rData(*reinterpret_cast<std::pair<void (*)(), boost::once_flag *> *>(pData));
-
-    if(*rData.second == false)
+namespace {
+    void *remote_call_proxy(void *pData)
     {
-        rData.first();
-        *rData.second = true;
+        std::pair<void (*)(), boost::once_flag *> &rData(*reinterpret_cast<std::pair<void (*)(), boost::once_flag *> *>(pData));
+
+        if(*rData.second == false)
+        {
+            rData.first();
+            *rData.second = true;
+        }
+
+        return(NULL);
+    }
+}
+#elif defined(BOOST_HAS_WINTHREADS)
+namespace {
+    // The signature for InterlockedCompareExchange has changed with the
+    // addition of Win64 support. I can't determine any (consistent and
+    // portable) way of using conditional compilation to detect this, so
+    // we use these type wrappers.  Unfortunately, the various vendors
+    // use different calling conventions and other signature anamolies,
+    // and thus have unique types as well.  This is known to work on VC6,
+    // VC7, Borland 5.5.2 and gcc 3.2.  Are there other signatures for
+    // other platforms?
+    inline LONG ice_wrapper(LONG (__stdcall *ice)(LONG*, LONG, LONG), volatile LONG* dest, LONG exch, LONG cmp)
+    {
+        return (*ice)(const_cast<LONG*>(dest), exch, cmp);
     }
 
-    return(NULL);
+    inline LONG ice_wrapper(LONG (__stdcall *ice)(volatile LONG*, LONG, LONG), volatile LONG* dest, LONG exch, LONG cmp)
+    {
+        return (*ice)(dest, exch, cmp);
+    }
+
+    inline LONG ice_wrapper(LPVOID (__stdcall *ice)(LPVOID*, LPVOID, LPVOID), volatile LONG* dest, LONG exch, LONG cmp)
+    {
+        return (LONG)(*ice)((LPVOID*)dest, (LPVOID)exch, (LPVOID)cmp);
+    }
+
+    // The friendly form of InterlockedCompareExchange that defers
+    // according to the above function type wrappers.
+    inline LONG compare_exchange(volatile LPLONG dest, LONG exch, LONG cmp)
+    {
+        return ice_wrapper(&InterlockedCompareExchange, dest, exch, cmp);
+    }
 }
 #endif
 
@@ -78,12 +112,7 @@ namespace boost {
 void call_once(void (*func)(), once_flag& flag)
 {
 #if defined(BOOST_HAS_WINTHREADS)
-    once_flag tmp = flag;
-
-    // Memory barrier would be needed here to prevent race conditions on some platforms with
-    // partial ordering.
-
-    if (!tmp)
+    if (compare_exchange(&flag, 1, 1) == 0)
     {
 #if defined(BOOST_NO_STRINGSTREAM)
         std::ostrstream strm;
@@ -101,16 +130,10 @@ void call_once(void (*func)(), once_flag& flag)
         res = WaitForSingleObject(mutex, INFINITE);
         assert(res == WAIT_OBJECT_0);
 
-        tmp = flag;
-        if (!tmp)
+        if (compare_exchange(&flag, 1, 1) == 0)
         {
             func();
-            tmp = true;
-
-            // Memory barrier would be needed here to prevent race conditions on some platforms
-            // with partial ordering.
-
-            flag = tmp;
+            InterlockedExchange(&flag, 1);
         }
 
         res = ReleaseMutex(mutex);
diff --git a/src/recursive_mutex.cpp b/src/recursive_mutex.cpp
index 0041b771..6ab84eeb 100644
--- a/src/recursive_mutex.cpp
+++ b/src/recursive_mutex.cpp
@@ -195,23 +195,35 @@ bool recursive_timed_mutex::do_trylock()
 
 bool recursive_timed_mutex::do_timedlock(const xtime& xt)
 {
-    int milliseconds;
-    to_duration(xt, milliseconds);
-
-    unsigned int res = 0;
-    res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), milliseconds);
-    assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
-
-    if (res == WAIT_OBJECT_0)
+    for (;;)
     {
-        if (++m_count > 1)
+        int milliseconds;
+        to_duration(xt, milliseconds);
+
+        unsigned int res = 0;
+        res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), milliseconds);
+        assert(res != WAIT_FAILED && res != WAIT_ABANDONED);
+
+        if (res == WAIT_TIMEOUT)
         {
-            res = ReleaseMutex(reinterpret_cast<HANDLE>(m_mutex));
-            assert(res);
+            xtime cur;
+            xtime_get(&cur, TIME_UTC);
+            if (xtime_cmp(xt, cur) > 0)
+                continue;
         }
-        return true;
+
+        if (res == WAIT_OBJECT_0)
+        {
+            if (++m_count > 1)
+            {
+                res = ReleaseMutex(reinterpret_cast<HANDLE>(m_mutex));
+                assert(res);
+            }
+            return true;
+        }
+
+        return false;
     }
-    return false;
 }
 
 void recursive_timed_mutex::do_unlock()
diff --git a/src/thread.cpp b/src/thread.cpp
index b27f1177..82dff69f 100644
--- a/src/thread.cpp
+++ b/src/thread.cpp
@@ -343,37 +343,44 @@ void thread::test_cancel()
 
 void thread::sleep(const xtime& xt)
 {
+    for (int foo=0; foo < 5; ++foo)
+    {
 #if defined(BOOST_HAS_WINTHREADS)
-    int milliseconds;
-    to_duration(xt, milliseconds);
-    Sleep(milliseconds);
+        int milliseconds;
+        to_duration(xt, milliseconds);
+        Sleep(milliseconds);
 #elif defined(BOOST_HAS_PTHREADS)
 #   if defined(BOOST_HAS_PTHREAD_DELAY_NP)
-    timespec ts;
-    to_timespec_duration(xt, ts);
-    int res = 0;
-    res = pthread_delay_np(&ts);
-    assert(res == 0);
+        timespec ts;
+        to_timespec_duration(xt, ts);
+        int res = 0;
+        res = pthread_delay_np(&ts);
+        assert(res == 0);
 #   elif defined(BOOST_HAS_NANOSLEEP)
-    timespec ts;
-    to_timespec_duration(xt, ts);
+        timespec ts;
+        to_timespec_duration(xt, ts);
 
-    //  nanosleep takes a timespec that is an offset, not
-    //  an absolute time.
-    nanosleep(&ts, 0);
+        //  nanosleep takes a timespec that is an offset, not
+        //  an absolute time.
+        nanosleep(&ts, 0);
 #   else
-    mutex mx;
-    mutex::scoped_lock lock(mx);
-    condition cond;
-    cond.timed_wait(lock, xt);
+        mutex mx;
+        mutex::scoped_lock lock(mx);
+        condition cond;
+        cond.timed_wait(lock, xt);
 #   endif
 #elif defined(BOOST_HAS_MPTASKS)
-    int microseconds;
-    to_microduration(xt, microseconds);
-    Duration lMicroseconds(kDurationMicrosecond * microseconds);
-    AbsoluteTime sWakeTime(DurationToAbsolute(lMicroseconds));
-    threads::mac::detail::safe_delay_until(&sWakeTime);
+        int microseconds;
+        to_microduration(xt, microseconds);
+        Duration lMicroseconds(kDurationMicrosecond * microseconds);
+        AbsoluteTime sWakeTime(DurationToAbsolute(lMicroseconds));
+        threads::mac::detail::safe_delay_until(&sWakeTime);
 #endif
+        xtime cur;
+        xtime_get(&cur, TIME_UTC);
+        if (xtime_cmp(xt, cur) <= 0)
+            return;
+    }
 }
 
 void thread::yield()
diff --git a/src/timeconv.inl b/src/timeconv.inl
index a82cbb88..508971ef 100644
--- a/src/timeconv.inl
+++ b/src/timeconv.inl
@@ -59,7 +59,7 @@ namespace {
         res = boost::xtime_get(&cur, boost::TIME_UTC);
         assert(res == boost::TIME_UTC);
 
-        if (xt.sec < cur.sec || (xt.sec == cur.sec && xt.nsec < cur.nsec))
+        if (boost::xtime_cmp(xt, cur) <= 0)
         {
             ts.tv_sec = 0;
             ts.tv_nsec = 0;
@@ -90,7 +90,7 @@ namespace {
         res = boost::xtime_get(&cur, boost::TIME_UTC);
         assert(res == boost::TIME_UTC);
 
-        if (xt.sec < cur.sec || (xt.sec == cur.sec && xt.nsec < cur.nsec))
+        if (boost::xtime_cmp(xt, cur) <= 0)
             milliseconds = 0;
         else
         {
@@ -107,7 +107,7 @@ namespace {
         res = boost::xtime_get(&cur, boost::TIME_UTC);
         assert(res == boost::TIME_UTC);
 
-        if (xt.sec < cur.sec || (xt.sec == cur.sec && xt.nsec < cur.nsec))
+        if (boost::xtime_get(&cur, boost::TIME_UTC) <= 0)
             microseconds = 0;
         else
         {
diff --git a/test/Jamfile b/test/Jamfile
index 355bb6fb..f6b2ebab 100644
--- a/test/Jamfile
+++ b/test/Jamfile
@@ -23,23 +23,30 @@ subproject libs/thread/test ;
 # 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.
-SEARCH on <module@>threads.jam = $(BOOST_ROOT)/libs/thread/build ;
-include <module@>threads.jam ;
+SEARCH on threads.jam = $(BOOST_ROOT)/libs/thread/build ;
+include threads.jam ;
+
+# bring in rules for testing
+SEARCH on testing.jam = $(BOOST_BUILD_PATH) ;
+include testing.jam ;
+
+sources = test.cpp test_thread.cpp test_mutex.cpp test_condition.cpp test_tss.cpp test_once.cpp ;
+
+template test
+    ## sources ##
+    : <template>thread_base <lib>../build/boost_thread <lib>../../test/build/unit_test_framework $(threadmon)
+    ## requirements ##
+    :
+    ## default build ##
+    : debug release <runtime-link>static/dynamic
+;
 
 #######################
 # Declare the Boost.Threads unit test program test_thread.
 
-# Base names of the source files for test_thread.
-CPP_SOURCES =
-    test_harness test_thread test_thread_group test_mutex test_rw_mutex test_condition test_tss test_call_once test_barrier test_thread_pool test_xtime ;
-
-unit-test test_harness
-    : $(CPP_SOURCES).cpp
-      <lib>../build/boost_thread
-      $(threadmon)
-    : <include>$(BOOST_ROOT)
-      $(pthreads-win32)
-      <threading>multi
-    : debug release <runtime-link>static/dynamic
-;
-
+run test_thread.cpp <template>test ;
+run test_mutex.cpp <template>test  ;
+run test_condition.cpp <template>test ;
+run test_tss.cpp <template>test ;
+run test_once.cpp <template>test ;
+run test_xtime.cpp <template>test ;
diff --git a/test/test.mcp b/test/test.mcp
index e391a34f..f27f0b97 100644
Binary files a/test/test.mcp and b/test/test.mcp differ
diff --git a/test/test_condition.cpp b/test/test_condition.cpp
index 9bded82d..d455d38e 100644
--- a/test/test_condition.cpp
+++ b/test/test_condition.cpp
@@ -1,41 +1,98 @@
+#include <boost/thread/condition.hpp>
 #include <boost/thread/thread.hpp>
 #include <boost/thread/xtime.hpp>
-#include <boost/thread/condition.hpp>
-#include <boost/test/test_tools.hpp>
 
-namespace {
+#include <boost/test/unit_test.hpp>
 
-struct condition_test_data
+namespace
 {
-    condition_test_data() : notified(0), awoken(0) { }
+    struct condition_test_data
+    {
+        condition_test_data() : notified(0), awoken(0) { }
 
-    boost::mutex mutex;
-    boost::condition condition;
-    int notified;
-    int awoken;
-};
+        boost::mutex mutex;
+        boost::condition condition;
+        int notified;
+        int awoken;
+    };
 
-void condition_test_thread(void* param)
-{
-    condition_test_data* data = static_cast<condition_test_data*>(param);
-    boost::mutex::scoped_lock lock(data->mutex);
-    BOOST_TEST(lock);
-    while (!(data->notified > 0))
-        data->condition.wait(lock);
-    BOOST_TEST(lock);
-    data->awoken++;
+    void condition_test_thread(void* param)
+    {
+        condition_test_data* data = static_cast<condition_test_data*>(param);
+        boost::mutex::scoped_lock lock(data->mutex);
+        BOOST_CHECK(lock ? true : false);
+        while (!(data->notified > 0))
+            data->condition.wait(lock);
+        BOOST_CHECK(lock ? true : false);
+        data->awoken++;
+    }
+
+    class thread_adapter
+    {
+    public:
+        thread_adapter(void (*func)(void*), void* param) : _func(func), _param(param) { }
+        void operator()() const { _func(_param); }
+    private:
+        void (*_func)(void*);
+        void* _param;
+    };
+
+    struct cond_predicate
+    {
+        cond_predicate(int& var, int val) : _var(var), _val(val) { }
+
+        bool operator()() { return _var == _val; }
+
+        int& _var;
+        int _val;
+    };
+
+    void condition_test_waits(void* param)
+    {
+        condition_test_data* data = static_cast<condition_test_data*>(param);
+
+        boost::mutex::scoped_lock lock(data->mutex);
+        BOOST_CHECK(lock ? true : false);
+
+        // Test wait.
+        while (data->notified != 1)
+            data->condition.wait(lock);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data->notified, 1);
+        data->awoken++;
+        data->condition.notify_one();
+
+        // Test predicate wait.
+        data->condition.wait(lock, cond_predicate(data->notified, 2));
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data->notified, 2);
+        data->awoken++;
+        data->condition.notify_one();
+
+        // Test timed_wait.
+        boost::xtime xt;
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.sec += 10;
+        while (data->notified != 3)
+            data->condition.timed_wait(lock, xt);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data->notified, 3);
+        data->awoken++;
+        data->condition.notify_one();
+
+        // Test predicate timed_wait.
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.sec += 10;
+        cond_predicate pred(data->notified, 4);
+        BOOST_CHECK(data->condition.timed_wait(lock, xt, pred));
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK(pred());
+        BOOST_CHECK_EQUAL(data->notified, 4);
+        data->awoken++;
+        data->condition.notify_one();
+    }
 }
 
-class thread_adapter
-{
-public:
-    thread_adapter(void (*func)(void*), void* param) : _func(func), _param(param) { }
-    void operator()() const { _func(_param); }
-private:
-    void (*_func)(void*);
-    void* _param;
-};
-
 void test_condition_notify_one()
 {
     condition_test_data data;
@@ -44,13 +101,13 @@ void test_condition_notify_one()
 
     {
         boost::mutex::scoped_lock lock(data.mutex);
-        BOOST_TEST(lock);
+        BOOST_CHECK(lock ? true : false);
         data.notified++;
         data.condition.notify_one();
     }
 
     thread.join();
-    BOOST_TEST(data.awoken == 1);
+    BOOST_CHECK_EQUAL(data.awoken, 1);
 }
 
 void test_condition_notify_all()
@@ -64,65 +121,13 @@ void test_condition_notify_all()
 
     {
         boost::mutex::scoped_lock lock(data.mutex);
-        BOOST_TEST(lock);
+        BOOST_CHECK(lock ? true : false);
         data.notified++;
         data.condition.notify_all();
     }
 
     threads.join_all();
-    BOOST_TEST(data.awoken == NUMTHREADS);
-}
-
-struct cond_predicate
-{
-    cond_predicate(int& var, int val) : _var(var), _val(val) { }
-
-    bool operator()() { return _var == _val; }
-
-    int& _var;
-    int _val;
-};
-
-void condition_test_waits(void* param)
-{
-    condition_test_data* data = static_cast<condition_test_data*>(param);
-
-    boost::mutex::scoped_lock lock(data->mutex);
-    BOOST_TEST(lock);
-
-    // Test wait.
-    while (data->notified != 1)
-        data->condition.wait(lock);
-    BOOST_TEST(lock);
-    BOOST_TEST(data->notified == 1);
-    data->awoken++;
-    data->condition.notify_one();
-
-    // Test predicate wait.
-    data->condition.wait(lock, cond_predicate(data->notified, 2));
-    BOOST_TEST(lock);
-    BOOST_TEST(data->notified == 2);
-    data->awoken++;
-    data->condition.notify_one();
-
-    // Test timed_wait.
-    boost::xtime xt;
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.nsec += 100000000;
-    while (data->notified != 3)
-        data->condition.timed_wait(lock, xt);
-    BOOST_TEST(lock);
-    BOOST_TEST(data->notified == 3);
-    data->awoken++;
-    data->condition.notify_one();
-
-    // Test predicate timed_wait.
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.sec += 2;
-    BOOST_TEST(data->condition.timed_wait(lock, xt, cond_predicate(data->notified, 4)));
-    BOOST_TEST(lock);
-    BOOST_TEST(data->notified == 4);
-    data->awoken++;
+    BOOST_CHECK_EQUAL(data.awoken, NUMTHREADS);
 }
 
 void test_condition_waits()
@@ -135,53 +140,63 @@ void test_condition_waits()
 
     {
         boost::mutex::scoped_lock lock(data.mutex);
-        BOOST_TEST(lock);
+        BOOST_CHECK(lock ? true : false);
 
-        BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
         xt.sec += 1;
         boost::thread::sleep(xt);
         data.notified++;
         data.condition.notify_one();
         while (data.awoken != 1)
             data.condition.wait(lock);
-        BOOST_TEST(data.awoken == 1);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data.awoken, 1);
 
-        BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
         xt.sec += 1;
         boost::thread::sleep(xt);
         data.notified++;
         data.condition.notify_one();
         while (data.awoken != 2)
             data.condition.wait(lock);
-        BOOST_TEST(data.awoken == 2);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data.awoken, 2);
 
-        BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
         xt.sec += 1;
         boost::thread::sleep(xt);
         data.notified++;
         data.condition.notify_one();
         while (data.awoken != 3)
             data.condition.wait(lock);
-        BOOST_TEST(data.awoken == 3);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data.awoken, 3);
+
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.sec += 1;
+        boost::thread::sleep(xt);
+        data.notified++;
+        data.condition.notify_one();
+        while (data.awoken != 4)
+            data.condition.wait(lock);
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK_EQUAL(data.awoken, 4);
     }
 
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.sec += 1;
-    boost::thread::sleep(xt);
-    data.notified++;
-    data.condition.notify_one();
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
+    BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
     xt.sec += 1;
     boost::thread::sleep(xt);
     thread.join();
-    BOOST_TEST(data.awoken == 4);
+    BOOST_CHECK_EQUAL(data.awoken, 4);
 }
 
-} // namespace
-
-void test_condition()
+boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
 {
-    test_condition_notify_one();
-    test_condition_notify_all();
-    test_condition_waits();
+    boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE("Boost.Threads: condition test suite");
+
+    test->add(BOOST_TEST_CASE(&test_condition_notify_one));
+    test->add(BOOST_TEST_CASE(&test_condition_notify_all));
+    test->add(BOOST_TEST_CASE(&test_condition_waits));
+
+    return test;
 }
diff --git a/test/test_mutex.cpp b/test/test_mutex.cpp
index ceaf9587..08417f24 100644
--- a/test/test_mutex.cpp
+++ b/test/test_mutex.cpp
@@ -1,188 +1,229 @@
-#include <boost/thread/thread.hpp>
-#include <boost/thread/xtime.hpp>
 #include <boost/thread/mutex.hpp>
 #include <boost/thread/recursive_mutex.hpp>
+#include <boost/thread/xtime.hpp>
 #include <boost/thread/condition.hpp>
-#include <boost/test/test_tools.hpp>
 
-namespace {
+#include <boost/test/unit_test.hpp>
+#include <boost/test/unit_test_suite_ex.hpp>
+
+namespace
+{
+    inline bool xtime_in_range(boost::xtime& xt, int less_seconds, int greater_seconds)
+    {
+        boost::xtime cur;
+        BOOST_CHECK_EQUAL(boost::xtime_get(&cur, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+
+        boost::xtime less = cur;
+        less.sec += less_seconds;
+
+        boost::xtime greater = cur;
+        greater.sec += greater_seconds;
+
+        return (boost::xtime_cmp(xt, less) >= 0) && (boost::xtime_cmp(xt, greater) <= 0);
+    }
+}
 
 template <typename M>
-void test_lock(M* dummy=0)
+struct test_lock
 {
     typedef M mutex_type;
     typedef typename M::scoped_lock lock_type;
 
-    mutex_type mutex;
-    boost::condition condition;
-
-    // Test the lock's constructors.
+    void operator()()
     {
-        lock_type lock(mutex, false);
-        BOOST_TEST(!lock);
+        mutex_type mutex;
+        boost::condition condition;
+
+        // Test the lock's constructors.
+        {
+            lock_type lock(mutex, false);
+            BOOST_CHECK(!lock);
+        }
+        lock_type lock(mutex);
+        BOOST_CHECK(lock ? true : false);
+
+        // Construct and initialize an xtime for a fast time out.
+        boost::xtime xt;
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.nsec += 100000000;
+
+        // Test the lock and the mutex with condition variables.
+        // No one is going to notify this condition variable.  We expect to
+        // time out.
+        BOOST_CHECK(!condition.timed_wait(lock, xt));
+        BOOST_CHECK(lock ? true : false);
+
+        // Test the lock and unlock methods.
+        lock.unlock();
+        BOOST_CHECK(!lock);
+        lock.lock();
+        BOOST_CHECK(lock ? true : false);
     }
-    lock_type lock(mutex);
-    BOOST_TEST(lock);
-
-    // Construct and initialize an xtime for a fast time out.
-    boost::xtime xt;
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.nsec += 100000000;
-
-    // Test the lock and the mutex with condition variables.
-    // No one is going to notify this condition variable.  We expect to
-    // time out.
-    BOOST_TEST(condition.timed_wait(lock, xt) == false);
-    BOOST_TEST(lock);
-
-    // Test the lock and unlock methods.
-    lock.unlock();
-    BOOST_TEST(!lock);
-    lock.lock();
-    BOOST_TEST(lock);
-}
+};
 
 template <typename M>
-void test_trylock(M* dummy=0)
+struct test_trylock
 {
-	typedef M mutex_type;
+    typedef M mutex_type;
     typedef typename M::scoped_try_lock try_lock_type;
 
-    mutex_type mutex;
-    boost::condition condition;
-
-    // Test the lock's constructors.
+    void operator()()
     {
-        try_lock_type lock(mutex);
-        BOOST_TEST(lock);
+        mutex_type mutex;
+        boost::condition condition;
+
+        // Test the lock's constructors.
+        {
+            try_lock_type lock(mutex);
+            BOOST_CHECK(lock ? true : false);
+        }
+        {
+            try_lock_type lock(mutex, false);
+            BOOST_CHECK(!lock);
+        }
+        try_lock_type lock(mutex, true);
+        BOOST_CHECK(lock ? true : false);
+
+        // Construct and initialize an xtime for a fast time out.
+        boost::xtime xt;
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.nsec += 100000000;
+
+        // Test the lock and the mutex with condition variables.
+        // No one is going to notify this condition variable.  We expect to
+        // time out.
+        BOOST_CHECK(!condition.timed_wait(lock, xt));
+        BOOST_CHECK(lock ? true : false);
+
+        // Test the lock, unlock and trylock methods.
+        lock.unlock();
+        BOOST_CHECK(!lock);
+        lock.lock();
+        BOOST_CHECK(lock ? true : false);
+        lock.unlock();
+        BOOST_CHECK(!lock);
+        BOOST_CHECK(lock.try_lock());
+        BOOST_CHECK(lock ? true : false);
     }
-    {
-        try_lock_type lock(mutex, false);
-        BOOST_TEST(!lock);
-    }
-    try_lock_type lock(mutex, true);
-    BOOST_TEST(lock);
-
-    // Construct and initialize an xtime for a fast time out.
-    boost::xtime xt;
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.nsec += 100000000;
-
-    // Test the lock and the mutex with condition variables.
-    // No one is going to notify this condition variable.  We expect to
-    // time out.
-    BOOST_TEST(condition.timed_wait(lock, xt) == false);
-    BOOST_TEST(lock);
-
-    // Test the lock, unlock and trylock methods.
-    lock.unlock();
-    BOOST_TEST(!lock);
-    lock.lock();
-    BOOST_TEST(lock);
-    lock.unlock();
-    BOOST_TEST(!lock);
-    BOOST_TEST(lock.try_lock());
-    BOOST_TEST(lock);
-}
+};
 
 template <typename M>
-void test_timedlock(M* dummy=0)
+struct test_timedlock
 {
     typedef M mutex_type;
     typedef typename M::scoped_timed_lock timed_lock_type;
 
-    mutex_type mutex;
-    boost::condition condition;
-
-    // Test the lock's constructors.
+    void operator()()
     {
+        mutex_type mutex;
+        boost::condition condition;
+
+        // Test the lock's constructors.
+        {
+            // Construct and initialize an xtime for a fast time out.
+            boost::xtime xt;
+            BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+            xt.nsec += 100000000;
+
+            timed_lock_type lock(mutex, xt);
+            BOOST_CHECK(lock ? true : false);
+        }
+        {
+            timed_lock_type lock(mutex, false);
+            BOOST_CHECK(!lock);
+        }
+        timed_lock_type lock(mutex, true);
+        BOOST_CHECK(lock ? true : false);
+
         // Construct and initialize an xtime for a fast time out.
         boost::xtime xt;
-        BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
         xt.nsec += 100000000;
 
-        timed_lock_type lock(mutex, xt);
-        BOOST_TEST(lock);
+        // Test the lock and the mutex with condition variables.
+        // No one is going to notify this condition variable.  We expect to
+        // time out.
+        BOOST_CHECK(!condition.timed_wait(lock, xt));
+        BOOST_CHECK(lock ? true : false);
+        BOOST_CHECK(xtime_in_range(xt, -1, 0));
+
+        // Test the lock, unlock and timedlock methods.
+        lock.unlock();
+        BOOST_CHECK(!lock);
+        lock.lock();
+        BOOST_CHECK(lock ? true : false);
+        lock.unlock();
+        BOOST_CHECK(!lock);
+        BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        xt.nsec += 100000000;
+        BOOST_CHECK(lock.timed_lock(xt));
+        BOOST_CHECK(lock ? true : false);
     }
+};
+
+template <typename M>
+struct test_recursive_lock
+{
+    typedef M mutex_type;
+    typedef typename M::scoped_lock lock_type;
+
+    void operator()()
     {
-        timed_lock_type lock(mutex, false);
-        BOOST_TEST(!lock);
+        mutex_type mx;
+        lock_type lock1(mx);
+        lock_type lock2(mx);
     }
-    timed_lock_type lock(mutex, true);
-    BOOST_TEST(lock);
-
-    // Construct and initialize an xtime for a fast time out.
-    boost::xtime xt;
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.nsec += 100000000;
-
-    // Test the lock and the mutex with condition variables.
-    // No one is going to notify this condition variable.  We expect to
-    // time out.
-    BOOST_TEST(condition.timed_wait(lock, xt) == false);
-    BOOST_TEST(lock);
-
-    // Test the lock, unlock and timedlock methods.
-    lock.unlock();
-    BOOST_TEST(!lock);
-    lock.lock();
-    BOOST_TEST(lock);
-    lock.unlock();
-    BOOST_TEST(!lock);
-    BOOST_TEST(boost::xtime_get(&xt, boost::TIME_UTC) == boost::TIME_UTC);
-    xt.nsec += 100000000;
-    BOOST_TEST(lock.timed_lock(xt));
-}
-
-} // namespace
+};
 
 void test_mutex()
 {
-    typedef boost::mutex mutex;
-    test_lock<mutex>();
+    test_lock<boost::mutex>()();
 }
 
 void test_try_mutex()
 {
-    typedef boost::try_mutex mutex;
-    test_lock<mutex>();
-    test_trylock<mutex>();
+    test_lock<boost::try_mutex>()();
+    test_trylock<boost::try_mutex>()();
 }
 
 void test_timed_mutex()
 {
-    typedef boost::timed_mutex mutex;
-    test_lock<mutex>();
-    test_trylock<mutex>();
-    test_timedlock<mutex>();
+    test_lock<boost::timed_mutex>()();
+    test_trylock<boost::timed_mutex>()();
+    test_timedlock<boost::timed_mutex>()();
 }
 
 void test_recursive_mutex()
 {
-    typedef boost::recursive_mutex mutex;
-    test_lock<mutex>();
-    mutex mx;
-    mutex::scoped_lock lock1(mx);
-    mutex::scoped_lock lock2(mx);
+    test_lock<boost::recursive_mutex>()();
+    test_recursive_lock<boost::recursive_mutex>()();
 }
 
 void test_recursive_try_mutex()
 {
-    typedef boost::recursive_try_mutex mutex;
-    test_lock<mutex>();
-    test_trylock<mutex>();
-    mutex mx;
-    mutex::scoped_lock lock1(mx);
-    mutex::scoped_lock lock2(mx);
+    test_lock<boost::recursive_try_mutex>()();
+    test_trylock<boost::recursive_try_mutex>()();
+    test_recursive_lock<boost::recursive_try_mutex>()();
 }
 
 void test_recursive_timed_mutex()
 {
-    typedef boost::recursive_timed_mutex mutex;
-    test_lock<mutex>();
-    test_trylock<mutex>();
-    test_timedlock<mutex>();
-    mutex mx;
-    mutex::scoped_lock lock1(mx);
-    mutex::scoped_lock lock2(mx);
+    test_lock<boost::recursive_timed_mutex>()();
+    test_trylock<boost::recursive_timed_mutex>()();
+    test_timedlock<boost::recursive_timed_mutex>()();
+    test_recursive_lock<boost::recursive_timed_mutex>()();
+}
+
+boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
+{
+    boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE("Boost.Threads: mutex test suite");
+
+    test->add(BOOST_TEST_CASE(&test_mutex));
+    test->add(BOOST_TEST_CASE(&test_try_mutex));
+    test->add(BOOST_TEST_CASE(&test_timed_mutex));
+    test->add(BOOST_TEST_CASE(&test_recursive_mutex));
+    test->add(BOOST_TEST_CASE(&test_recursive_try_mutex));
+    test->add(BOOST_TEST_CASE(&test_recursive_timed_mutex));
+
+    return test;
 }
diff --git a/test/test_thread.cpp b/test/test_thread.cpp
index 075c3638..a914a4dd 100644
--- a/test/test_thread.cpp
+++ b/test/test_thread.cpp
@@ -1,97 +1,89 @@
 #include <boost/thread/thread.hpp>
 #include <boost/thread/xtime.hpp>
-#include <boost/test/test_tools.hpp>
+//#include <boost/test/test_tools.hpp>
+#include <boost/test/unit_test.hpp>
 
-#include <utils.inl>
-
-namespace {
-
-int test_value;
-
-struct thread_comparison_adapter
+namespace
 {
-	thread_comparison_adapter(void (*func)(boost::thread& parent), boost::thread& parent)
-		: func(func), parent(parent)
-	{
-	}
+    inline bool xtime_in_range(boost::xtime& xt, int less_seconds, int greater_seconds)
+    {
+        boost::xtime cur;
+        BOOST_CHECK_EQUAL(boost::xtime_get(&cur, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
 
-	void operator()()
-	{
-		(*func)(parent);
-	}
+        boost::xtime less = cur;
+        less.sec += less_seconds;
 
-	void (*func)(boost::thread& parent);
-	boost::thread& parent;
-};
+        boost::xtime greater = cur;
+        greater.sec += greater_seconds;
+
+        return (boost::xtime_cmp(xt, less) >= 0) && (boost::xtime_cmp(xt, greater) <= 0);
+    }
+
+    int test_value;
+
+    void simple_thread()
+    {
+        test_value = 999;
+    }
+
+    struct thread_adapter
+    {
+        thread_adapter(void (*func)(boost::thread& parent), boost::thread& parent)
+            : func(func), parent(parent)
+        {
+        }
+
+        void operator()()
+        {
+            (*func)(parent);
+        }
+
+        void (*func)(boost::thread& parent);
+        boost::thread& parent;
+    };
+
+    void comparison_thread(boost::thread& parent)
+    {
+        boost::thread thrd;
+        BOOST_TEST(thrd != parent);
+        BOOST_TEST(thrd == boost::thread());
+    }
+}
 
 void test_sleep()
 {
-	boost::xtime xt;
-	xtime_get(xt, 5);
-	boost::thread::sleep(xt);
-	// Insure it's in a range instead of checking actual equality due to time lapse
-	BOOST_TEST(xtime_in_range(xt, -1, 1));
-}
+    boost::xtime xt;
+    BOOST_CHECK_EQUAL(boost::xtime_get(&xt, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+    xt.sec += 3;
 
-void simple_thread()
-{
-	test_value = 999;
+    boost::thread::sleep(xt);
+
+    // Insure it's in a range instead of checking actual equality due to time lapse
+    BOOST_CHECK(xtime_in_range(xt, -1, 0));
 }
 
 void test_creation()
 {
-	try
-	{
-		test_value = 0;
-		boost::thread thrd(&simple_thread);
-		thrd.join();
-		// If creation fails there's little point in continuing...
-		BOOST_CRITICAL_TEST(test_value == 999);
-	}
-	catch (boost::thread_resource_error&)
-	{
-		BOOST_CRITICAL_ERROR("Caught thread_resource_error");
-	}
-}
-
-void comparison_thread(boost::thread& parent)
-{
-	boost::thread thrd;
-	BOOST_TEST(thrd != parent);
-	BOOST_TEST(thrd == boost::thread());
-}
-
-void cancelation_thread()
-{
-	for (;;)
-	{
-		boost::thread::test_cancel();
-		boost::xtime xt;
-		xtime_get(xt, 1);
-		boost::thread::sleep(xt);
-	}
+    test_value = 0;
+    boost::thread thrd(&simple_thread);
+    thrd.join();
+    BOOST_CHECK_EQUAL(test_value, 999);
 }
 
 void test_comparison()
 {
-	boost::thread self;
-	boost::thread thrd(thread_comparison_adapter(&comparison_thread, self));
-	thrd.join();
+    boost::thread self;
+    boost::thread thrd(thread_adapter(comparison_thread, self));
+    thrd.join();
 }
 
-void test_cancel()
+boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
 {
-	boost::thread thrd(&cancelation_thread);
-	thrd.cancel();
-	thrd.join();
+    boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE("Boost.Threads: thread test suite");
+
+    test->add(BOOST_TEST_CASE(test_sleep));
+    test->add(BOOST_TEST_CASE(test_creation));
+    test->add(BOOST_TEST_CASE(test_comparison));
+
+    return test;
 }
-
-} // namespace
-
-void test_thread()
-{
-	test_sleep();
-	test_creation();
-	test_comparison();
-	test_cancel();
-}
\ No newline at end of file
diff --git a/test/test_tss.cpp b/test/test_tss.cpp
index f03c7ce2..ccb4ff62 100644
--- a/test/test_tss.cpp
+++ b/test/test_tss.cpp
@@ -1,68 +1,59 @@
-#include <boost/thread/thread.hpp>
-#include <boost/thread/mutex.hpp>
 #include <boost/thread/tss.hpp>
-#include <boost/test/test_tools.hpp>
+#include <boost/thread/mutex.hpp>
+#include <boost/thread/thread.hpp>
 
-#include <iostream>
+#include <boost/test/unit_test.hpp>
 
-namespace {
-
-boost::mutex tss_mutex;
-int tss_instances = 0;
-
-struct tss_value_t
+namespace
 {
-    tss_value_t()
-    {
-        boost::mutex::scoped_lock lock(tss_mutex);
-        ++tss_instances;
-        value = 0;
-    }
-    ~tss_value_t()
-    {
-        boost::mutex::scoped_lock lock(tss_mutex);
-        --tss_instances;
-    }
-    int value;
-};
+    boost::mutex tss_mutex;
+    int tss_instances = 0;
 
-boost::thread_specific_ptr<tss_value_t>* tss_value = 0;
-//boost::thread_specific_ptr<tss_value_t> tss_value_no_delete(0);
-
-void test_tss_thread()
-{
-	boost::thread_specific_ptr<tss_value_t>& tss = *tss_value;
-	BOOST_TEST(tss.get() == 0);
-	tss_value_t* p = new tss_value_t();
-    tss.reset(p);
-	BOOST_TEST(tss.get() == p);
-
-    for (int i=0; i<1; ++i)
+    struct tss_value_t
     {
-        BOOST_TEST(tss->value == i);
-        ++tss->value;
+        tss_value_t()
+        {
+            boost::mutex::scoped_lock lock(tss_mutex);
+            ++tss_instances;
+            value = 0;
+        }
+        ~tss_value_t()
+        {
+            boost::mutex::scoped_lock lock(tss_mutex);
+            --tss_instances;
+        }
+        int value;
+    };
+
+    boost::thread_specific_ptr<tss_value_t> tss_value;
+
+    void test_tss_thread()
+    {
+        tss_value.reset(new tss_value_t());
+        for (int i=0; i<1000; ++i)
+        {
+            int& n = tss_value->value;
+            BOOST_CHECK_EQUAL(n, i);
+            ++n;
+        }
     }
 }
 
-} // namespace
-
-void test_thread_specific_ptr()
+void test_tss()
 {
-	{
-		boost::thread_specific_ptr<tss_value_t> tss;
-		tss_value = &tss;
-
-		BOOST_TEST(tss.get() == 0);
-		tss_value_t* p = new tss_value_t();
-		tss.reset(p);
-		BOOST_TEST(tss.get() == p);
-
-		const int NUMTHREADS=2;
-		boost::thread_group threads;
-		for (int i=0; i<NUMTHREADS; ++i)
-			threads.create_thread(&test_tss_thread);
-		threads.join_all();
-		BOOST_TEST(tss_instances == 1);
-	}
-	BOOST_TEST(tss_instances == 0);
+    const int NUMTHREADS=5;
+    boost::thread_group threads;
+    for (int i=0; i<NUMTHREADS; ++i)
+        threads.create_thread(&test_tss_thread);
+    threads.join_all();
+    BOOST_CHECK_EQUAL(tss_instances, 0);
+}
+
+boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
+{
+    boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE("Boost.Threads: tss test suite");
+
+    test->add(BOOST_TEST_CASE(test_tss));
+
+    return test;
 }
diff --git a/test/test_xtime.cpp b/test/test_xtime.cpp
index d354f7f1..ea43bdf3 100644
--- a/test/test_xtime.cpp
+++ b/test/test_xtime.cpp
@@ -1,11 +1,50 @@
-#include <boost/thread/thread.hpp>
 #include <boost/thread/xtime.hpp>
-#include <boost/test/test_tools.hpp>
+
+#include <boost/test/unit_test.hpp>
+
+void test_xtime_cmp()
+{
+    boost::xtime xt1, xt2, cur;
+    BOOST_CHECK_EQUAL(boost::xtime_get(&cur, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+
+    xt1 = xt2 = cur;
+    xt1.nsec -= 1;
+    xt2.nsec += 1;
+
+    BOOST_CHECK(boost::xtime_cmp(xt1, cur) < 0);
+    BOOST_CHECK(boost::xtime_cmp(xt2, cur) > 0);
+    BOOST_CHECK(boost::xtime_cmp(cur, cur) == 0);
+
+    xt1 = xt2 = cur;
+    xt1.sec -= 1;
+    xt2.sec += 1;
+
+    BOOST_CHECK(boost::xtime_cmp(xt1, cur) < 0);
+    BOOST_CHECK(boost::xtime_cmp(xt2, cur) > 0);
+    BOOST_CHECK(boost::xtime_cmp(cur, cur) == 0);
+}
 
 void test_xtime_get()
 {
-	boost::xtime xt;
+    boost::xtime orig, cur, old;
+    BOOST_CHECK_EQUAL(boost::xtime_get(&orig, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+    old = orig;
 
-	// If this fails we can't really run any tests, so we'll flag a critical error
-	BOOST_CRITICAL_TEST(boost::TIME_UTC == boost::xtime_get(&xt, boost::TIME_UTC));
-}
\ No newline at end of file
+    for (int x=0; x < 100; ++x)
+    {
+        BOOST_CHECK_EQUAL(boost::xtime_get(&cur, boost::TIME_UTC), static_cast<int>(boost::TIME_UTC));
+        BOOST_CHECK(boost::xtime_cmp(cur, orig) >= 0);
+        BOOST_CHECK(boost::xtime_cmp(cur, old) >= 0);
+        old = cur;
+    }
+}
+
+boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
+{
+    boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE("Boost.Threads: xtime test suite");
+
+    test->add(BOOST_TEST_CASE(&test_xtime_cmp));
+    test->add(BOOST_TEST_CASE(&test_xtime_get));
+
+    return test;
+}
diff --git a/tutorial/.cvsignore b/tutorial/.cvsignore
new file mode 100644
index 00000000..14acbe0d
--- /dev/null
+++ b/tutorial/.cvsignore
@@ -0,0 +1,2 @@
+bin
+*.pdb
\ No newline at end of file
diff --git a/tutorial/Jamfile b/tutorial/Jamfile
index 166ada2e..ad1451d9 100644
--- a/tutorial/Jamfile
+++ b/tutorial/Jamfile
@@ -26,10 +26,5 @@ template tutorial
 exe helloworld : <template>tutorial helloworld.cpp ;
 exe helloworld2 : <template>tutorial helloworld2.cpp ;
 exe helloworld3 : <template>tutorial helloworld3.cpp ;
-exe helloworld4 : <template>tutorial helloworld4.cpp ;
 exe factorial : <template>tutorial factorial.cpp ;
 exe factorial2 : <template>tutorial factorial2.cpp ;
-exe factorial3 : <template>tutorial factorial3.cpp ;
-exe counter : <template>tutorial counter.cpp ;
-exe bounded_buffer : <template>tutorial bounded_buffer.cpp ;
-exe once : <template>tutorial once.cpp ;
diff --git a/tutorial/helloworld2.cpp b/tutorial/helloworld2.cpp
index 378897cd..85874da1 100644
--- a/tutorial/helloworld2.cpp
+++ b/tutorial/helloworld2.cpp
@@ -3,12 +3,13 @@
 
 struct helloworld
 {
-    helloworld() { }
-    void operator()() { std::cout << "Hello World." << std::endl; }
+    helloworld(const char* who) : m_who(who) { }
+    void operator()() { std::cout << m_who << "says, \"Hello World.\"" << std::endl; }
+    const char* m_who;
 };
 
 int main()
 {
-    boost::thread thrd(helloworld());
+    boost::thread thrd(helloworld("Bob"));
     thrd.join();
 }
\ No newline at end of file
diff --git a/tutorial/helloworld3.cpp b/tutorial/helloworld3.cpp
index 85874da1..20628323 100644
--- a/tutorial/helloworld3.cpp
+++ b/tutorial/helloworld3.cpp
@@ -1,15 +1,14 @@
 #include <boost/thread/thread.hpp>
+#include <boost/bind.hpp>
 #include <iostream>
 
-struct helloworld
+void helloworld(const char* who)
 {
-    helloworld(const char* who) : m_who(who) { }
-    void operator()() { std::cout << m_who << "says, \"Hello World.\"" << std::endl; }
-    const char* m_who;
-};
+    std::cout << who << "says, \"Hello World.\"" << std::endl;
+}
 
 int main()
 {
-    boost::thread thrd(helloworld("Bob"));
+    boost::thread thrd(boost::bind(&helloworld, "Bob"));
     thrd.join();
 }
\ No newline at end of file

[Andrews 83]	Gregory R. Andrews, Fred B. Schneider, Concepts and - Notations for Concurrent Programming, ACM Computing Surveys, Vol. +	Gregory R. Andrews, Fred B. Schneider, Concepts and + Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March, 1983. - http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/ - Good general background reading. Includes descriptions of Path Expressions, + "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/ + Good general background reading. Includes descriptions of Path Expressions, Message Passing, and Remote Procedure Call in addition to the basics.
[Boost]	The Boost worldwide web site. http://www.boost.org - 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 + "http://www.boost.org">http://www.boost.org + 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.
[Brinch Hansen 73]	Per Brinch Hansen, Concurrent Programming Concepts, +	Per Brinch Hansen, Concurrent Programming Concepts, ACM Computing Surveys, Vol. 5, No. 4, December, 1973. - http://www.acm.org/pubs/articles/journals/surveys/1973-5-4/p223-hansen/ - "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 + "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/ + "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.
]Butenhof 97]	- David R. Butenhof, Programming with POSIX Threads, Addison-Wesley +	+ David R. Butenhof, Programming with POSIX Threads, Addison-Wesley 1997, ISBN 0-201-63392-2 + href="http://cseng.aw.com/book/0,3828,0201633922,00.html"> http://cseng.aw.com/book/0,3828,0201633922,00.html - 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 + 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.
[Hoare 74]	- C.A.R Hoare, Monitors: An Operating System Structuring Concept, - Communications of the ACM, Vol. 17, No. 10. October 1974, pp. 549-557 +	+ C.A.R Hoare, Monitors: An Operating System Structuring Concept, + Communications of the ACM, Vol. 17, No. 10. October 1974, pp. 549-557 http://www.acm.org/classics/feb96/ - Hoare and Brinch Hansen's work on Monitors is the basis for reliable - multithreading patterns. This is one of the most often referenced papers + 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.
[ISO 98]	- ISO/IEC 14882:1998(E) Programming Language C++ +	+ ISO/IEC 14882:1998(E) Programming Language C++ http://www.ansi.org - This is the official C++ Standards document. Available from the ANSI + This is the official C++ Standards document. Available from the ANSI (American National Standards Institute) Electronic Standards Store.
[McDowell 89]	Charles E McDowell, David P. Helmbold, Debugging Concurrent - Programs, ACM Computing Surveys, Vol. 21, No. 2, December, 1989. +	Charles E McDowell, David P. Helmbold, Debugging Concurrent + Programs, ACM Computing Surveys, Vol. 21, No. 2, December, 1989. - http://www.acm.org/pubs/citations/journals/surveys/1989-21-4/p593-mcdowell/ - Identifies many of the unique failure modes and debugging difficulties + "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/ + Identifies many of the unique failure modes and debugging difficulties associated with concurrent programs.
[Schmidt]	- Douglas C. Schmidt and Irfan Pyarali, Strategies for Implementing - POSIX Condition Variables on Win32, Department of Computer Science, +	+ Douglas C. Schmidt and Irfan Pyarali, Strategies for Implementing + POSIX Condition Variables on Win32, Department of Computer Science, Washington University, St. Louis, Missouri. http://www.cs.wustl.edu/~schmidt/win32-cv-1.html - 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 + 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.
[Schmidt 00]	- Douglas C. Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann, Pattern-Oriented - Software Architecture Volume 2 - Patterns for Concurrent and Networked +	+ Douglas C. Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann, Pattern-Oriented + Software Architecture Volume 2 - Patterns for Concurrent and Networked Objects, Wiley 2000, ISBN 0-471-60695-2 + "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 - This is a very good explanation of how to apply several patterns useful - for concurrent programming. Among the patterns documented is the Monitor + 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.
[Stroustrup 00]	Bjarne Stroustrup, The C++ Programming Language, +	Bjarne Stroustrup, The C++ Programming Language, Special Edition, Addison-Wesley 2000, ISBN 0-201-70073-5 http://cseng.aw.com/book/0,3828,0201700735,00.html - The first book a C++ programmer should own. Note that the 3rd edition - (and subsequent editions like the Special Edition) has been rewritten + "http://cseng.aw.com/book/0,3828,0201700735,00.html"> http://cseng.aw.com/book/0,3828,0201700735,00.html + 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.
Macro	Meaning
BOOST_HAS_THREADS	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'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 +	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'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.
Macro	Meaning
BOOST_HAS_WINTHREADS	Indicates that the platform has the Microsoft Win32 threading libraries, +	Indicates that the platform has the Microsoft Win32 threading libraries, and that they should be used to implement Boost.Threads.
BOOST_HAS_PTHREADS	Indicates that the platform has the POSIX pthreads libraries, and that +	Indicates that the platform has the POSIX pthreads libraries, and that they should be used to implement Boost.Threads.
BOOST_HAS_FTIME	Indicates that the implementation should use GetSystemTimeAsFileTime() - and the FILETIME type to calculate the current time. This is an implementation +	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().
BOOST_HAS_GETTTIMEOFDAY	Indicates that the implementation should use gettimeofday() to calculate +	Indicates that the implementation should use gettimeofday() to calculate the current time. This is an implementation detail used by boost::detail::getcurtime().
State	Description
Ready	Ready to run, but waiting for a processor.
Running	Currently executing on a processor. Zero or more threads may be running +	Currently executing on a processor. Zero or more threads may be running at any time, with a maximum equal to the number of processors.
Blocked	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]. +	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 for "blocked"
Terminated	Finished execution but not yet detached or joined.
From	To	Cause
+
[none]	Ready	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 +	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].
Ready	Running	Processor becomes available.
Running	Ready	Thread preempted.
Running	Blocked	Thread calls a library function which waits for a resource or for the +	Thread calls a library function which waits for a resource or for the completion of I/O.
Running	Terminated	Thread returns from its initial function, calls a thread termination library - function, or is canceled by some other thread calling a thread termination +	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.
Blocked	Ready	The resource being waited for becomes available, or the blocking library +	The resource being waited for becomes available, or the blocking library function completes.
Terminated	[none]	Thread is detached or joined by some other thread calling the appropriate +	Thread is detached or joined by some other thread calling the appropriate library function, or by program termination [3.6.3].
Thread A	Thread B
The sequence point at a call to a library thread-creation function.	The first sequence point of the initial function in the new thread created +	The first sequence point of the initial function in the new thread created by the Thread A call.
The sequence point at a call to a library function which locks a mutex, +
The sequence point at a call to a library function which locks a mutex, directly or by waiting for a condition variable.	The sequence point after a call to a library function which unlocks the +	The sequence point after a call to a library function which unlocks the same mutex.
The last sequence point before thread termination.	The sequence point after a call to a library function which joins the +	The sequence point after a call to a library function which joins the terminated thread.
The sequence point at a call to a library function which signals or broadcasts +
The sequence point at a call to a library function which signals or broadcasts a condition variable.	The sequence point after the call to the library function which was waiting +	The sequence point after the call to the library function which was waiting on that same condition variable or signal.
Expression	Effects
`(&lk)->~L();`	`if (locked()) unlock();`
`(&clk)->operator const void*()`	Returns type void*, non-zero if if the associated mutex object has been +	Returns type void*, non-zero if if the associated mutex object has been locked by `clk`, otherwise 0.
`clk.locked()`	Returns a `bool`, `(&clk)->operator const void*() +`	Returns a `bool`, `(&clk)->operator const void*() != 0`
`lk.lock()`	Throws `lock_error` if `locked()`. If the associated - mutex object is already locked by some other thread, places the current - thread in the Blocked state until the - associated mutex is unlocked, after which the current thread is placed in - the Ready state, eventually to be - returned to the Running state. If the - associated mutex object is already locked by the same thread the behavior - is dependent on the locking +	Throws `lock_error` if `locked()`. If the associated + mutex object is already locked by some other thread, places the current + thread in the Blocked state until the + associated mutex is unlocked, after which the current thread is placed in + the Ready state, eventually to be + returned to the Running state. If the + associated mutex object is already locked by the same thread the behavior + is dependent on the locking strategy of the associated mutex object. Postcondition: `locked() == true`
`lk.unlock()`	If `!locked()`, throws `lock_error`, otherwise unlocks +	If `!locked()`, throws `lock_error`, otherwise unlocks the associated mutex. Postcondition: `!locked()`
Expression	Effects
`L lk(m);`	Constructs an object `lk`, and associates mutex object `m` +	Constructs an object `lk`, and associates mutex object `m` with it, then calls `lock()`
`L lk(m,b);`	Constructs an object `lk`, and associates mutex object `m` +	Constructs an object `lk`, and associates mutex object `m` with it, then if `b`, calls `lock()`
Expression	Effects
`L lk(m,t);`	Constructs an object `lk`, and associates mutex object `m` +	Constructs an object `lk`, and associates mutex object `m` with it, then calls `timed_lock(t)`
`L lk(m,b);`	Constructs an object `lk`, and associates mutex object `m` +	Constructs an object `lk`, and associates mutex object `m` with it, then if `b`, calls `lock()`
`lk.timed_lock(t)`	If locked(), throws lock_error. Makes a blocking attempt to lock the associated - mutex object, and returns `true` if successful within the specified - time `t`, otherwise `false`. If the associated mutex - object is already locked by the same thread the behavior is dependent on - the locking strategy +	If locked(), throws lock_error. Makes a blocking attempt to lock the associated + mutex object, and returns `true` if successful within the specified + time `t`, otherwise `false`. If the associated mutex + object is already locked by the same thread the behavior is dependent on + the locking strategy of the associated mutex object.
Mutex Class	Lock name	Lock Concept
`mutex`	`scoped_lock`	ScopedLock
`try_mutex` +
`try_mutex`	`scoped_lock scoped_try_lock`	ScopedLock ScopedTryLock
`timed_mutex` +
`timed_mutex`	`scoped_lock scoped_try_lock @@ -95,22 +95,22 @@ ScopedTimedLock`