From 9b8c62d45a5f462752c0136dc5b499069b0fba74 Mon Sep 17 00:00:00 2001
From: "William E. Kempf" <wekempf@cox.net>
Date: Tue, 5 Nov 2002 22:43:42 +0000
Subject: [PATCH] Merged from RC_1_29_0

[SVN r16126]
---
 build/Jamfile                      |  24 +-
 build/threads.jam                  |  15 +-
 build/threads.mcp                  | Bin 91726 -> 5727 bytes
 doc/acknowledgments.html           |  64 +++---
 doc/bibliography.html              | 146 ++++++------
 doc/condition.html                 | 219 ++++++------------
 doc/configuration.html             |  68 +++---
 doc/definitions.html               | 194 ++++++++--------
 doc/exceptions.html                |  74 +++---
 doc/faq.html                       | 158 ++++++-------
 doc/index.html                     |  83 ++++---
 doc/introduction.html              | 182 +++++++--------
 doc/lock_concept.html              | 172 +++++++-------
 doc/mutex.html                     | 177 ++++++---------
 doc/mutex_concept.html             | 214 ++++++++---------
 doc/once.html                      |  66 ++----
 doc/overview.html                  | 146 ++++++------
 doc/rationale.html                 | 354 ++++++++++++++---------------
 doc/recursive_mutex.html           | 164 +++++--------
 doc/thread.html                    | 239 ++++++++-----------
 doc/tss.html                       |  99 +++-----
 doc/xtime.html                     |  69 +++---
 example/Jamfile                    |  70 ++----
 include/boost/thread/condition.hpp |   4 +-
 include/boost/thread/once.hpp      |   4 +-
 include/boost/thread/xtime.hpp     |   7 +
 src/condition.cpp                  |  26 ++-
 src/mac/safe.cpp                   |   4 +-
 src/mutex.cpp                      |  23 +-
 src/once.cpp                       |  67 ++++--
 src/recursive_mutex.cpp            |  38 ++--
 src/thread.cpp                     |  51 +++--
 src/timeconv.inl                   |   6 +-
 test/Jamfile                       |  39 ++--
 test/test.mcp                      | Bin 53600 -> 3675 bytes
 test/test_condition.cpp            | 225 +++++++++---------
 test/test_mutex.cpp                | 303 +++++++++++++-----------
 test/test_thread.cpp               | 142 ++++++------
 test/test_tss.cpp                  | 105 ++++-----
 test/test_xtime.cpp                |  51 ++++-
 tutorial/.cvsignore                |   2 +
 tutorial/Jamfile                   |   5 -
 tutorial/helloworld2.cpp           |   7 +-
 tutorial/helloworld3.cpp           |  11 +-
 44 files changed, 1994 insertions(+), 2123 deletions(-)
 create mode 100644 tutorial/.cvsignore

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 70ed21bffcdf4eacac6f353cb47ba2bb5a031860..ba3aaeff3e809f5e7b588a09ca12b52a095c0fe9 100644
GIT binary patch
delta 23
fcmX?ihV{PA1TiKBg^l7BqAUsu3JQ}ah@J)jVDJZT

literal 91726
zcmYe!&(C3CU|?ooVANn>jNxNoj5T9m;FMrsU`S+SVq|~;=lqn^@Wi5`%={vSfTH}Y
z)Z`MF)QF&+6N{4a^Av(hQWTuEwH2K6^NRCxQmukgbMs456<ku2O4Au|sBtVU$=5AO
zEJ{x;!KEZ1F*!RiJ+(+7ATcjB2bZeg{L-T2RE3bD)YM{JY8;c3Q;Ulg0uoCyaH;{j
z7GzscX<kWYZYnObLcnfT2u>|2$;?Z~X`EYTPO5@$VnG2uMNXxeIVlRR6(vQ9I1Pfk
z3t}-YXE~P^m*nRvc&ApD=NF~mG|kMyTLF}6-Ba^$nFLbel3AQsT%4Mll#^P7Pn~;C
zeo|tNf`36tW^QH`eziWCdD-|?z_JjIB;%|PNo2VNnRuK9Q5Bw8l!q_mo!xxREWB}f
z%`GGVf1>kBEK5{y&d<$F%u7-5$;`u<TEGf@67$ka6Vvf4@(uEGEGPh{2;89rHqO7a
zq@WaMt^q3{5RxD@F8RsuG7Cq5`z9v)2P^od7Nw`+4-SZn6x?zWac78t0B1re52S>c
zlm}8rY{~<v#h>y(Dgs>HaHR#XG_-8T5l#UC&W^>o_=6}YwF;DAAW0V*JqqAL!Y8vB
zXJmpbhh|p=-^An$U4MMegs1?eM?4t~WF%A}{t_iTGcO1fW%#pOg@qZRXay-DCR#!2
zTq}}O3raHc^FXCFo>CvAme?c!Qj0$cfK))^1ZVhy^9-m)OV7+pXK>2TFD}sw$tX%q
zOtC_#f>2~oDjpOWc(D$vZct<)F@vaNP$a>r241zGNP&wFScQTj1Gf)iG^z(sDr^*O
z$kjB81bTggDv4TBW08ZG&nR-31rCZdN-={XgVt0)l|w3ca7n;27lu4ay2X&iNP!qC
zpy>`n9GU|ONMnmDQ2qrKR~SaZ5-_?1qG&>qK`D@sWr}g9=VB|I3A)${p2D!D=wd5~
zU$7_XVk_Kfy4VV5qDHb4VmeByE=FyKqIwZmx-PcDm#~YiAgv4Md}yJFYA8e!Ytk;Z
z!k@N_t#BspVk<nUyVwep9-vhOn)i`pu%&N^R-6eOB8@kNLzG}i!w?DFX&gl!Yt(_<
zj-JXPy09g4unhKe4oU?`H7`npL3${7k~>rZ?nDn&fIsO&6+!%oBLhIy;K>G16}U44
zQ~}&A5c^Qm1XK;q^1c|V0B81q%Hz!>Fg3U<0hl%TG7Qud0@((t3U}s#D!`Y8U`lY*
z6EMeuk|Z>vVa-lR#^BCWNQ&@hEhL55G8mFHo@|Dx3QwW{`41z@A(?<R<00g6WIw0^
zl-g!QjE#(Xax?@+NC?0NL{%6V7?_}bc883gf_b?N3=Aw_76ZdX1_lOJD0?dd0|OhB
zeV2iOfgQqT1gYhKvNahP7&xJ9Uj_ySE+`u`(8>*E&t_m?;DNIDF)%RjLfOw47#R2<
zY$hQF1_pj8+k}CEK>*4QXJB9ugtBWH7#Kk6K;Br)z`!636+g(pz#sx;KVo2D5QVUr
zLH3J5*#-;@4B}9B6axbTXsj3%1Rygdq2db}7#O6W>=O(O4AM~cM+OE483>yNWVS4n
zZNb36AO~e9FfcI4L)kqH3=9fT_BsXz21O|QECU0B5|sUcfq_98!e#}z9TYd9pa+?$
z3KjQaU|>*#vO(dg4rR|}U|`UIvX3z^Fo5C!r1uR21A`VsoDCF~+EBJR0|SE&l%34L
zz@Q6d_cJgs=t0>V85kJ!q3kOR3=E*~0!9BX1_lO0h&VgQokmbLNS`s3?Zd#p0E#nE
z63Jv>U@(P>w=gg;m_ga|7#J8p?f|LT&A`9_@+XLWm4Si55~}7M0|SE<gv|kpJ8LK#
z<Zl}&+nIrZ!4}F+VqjpfgR*NF7#QrK>=_IU3=U8>$X||7_C*E;1}7-{Jp%&+$ShFu
z1*I<+h&U%GEM1{&4+aJXHz+%ufq?;(XF%#fc7fzT?5PY444zOm>lqjrKyd~VKgqzr
z;0+aj!oa`)3L}vCe+C8yP(A@=6;RsogQ(#G`OhE9j$mM52!OJS85kG>p=?mz41%)P
zFfcF#L)oA-5CUa`><Wdjxk33p49W)C1<Fed3=G_$Fay~EVn;GCFn}<KUB<w`0LmL6
z_5=n7hG?i>P#DHQ*%ufX7-FI9&kPI<aS%2SD1XO8*`Txr$`7Dy5At^+R2&pvAPf=*
zg&`;{g4oj;7#LEZYBn)2Fr-4+ml+rs(xB`w3=9mQH~<wNp!}Kv5$6S^1yGs;iG%FV
zf{HgVFfe38*-IE07(nwyAT>uB7#Kk19f<vufq@|pqJ|GthUG)qAomwQ*`PQngtAK+
z7#ND6>}d=P44}9H6=6FW7#KkL6U4sBz`y`f2P@7%VG3e{@^m>wFFz>GE1+zUTPmUK
z$qWn(RZup_%xWkblt)0}1v2L=0|Nu7%mNjWpt7wFq6Q}k%DbSv2FjD5yamcrp!^2P
z$Dq6k%D14j2MR|}x&Y-NP~HLM8BksU<q=Tc0Obi#UI66*P}&FOWl*{Yl@p+H02F7S
zFb2g1C`>_N3Gy2#{y=d8iZ4)@g2ECMhM=$mg&8QUKw$(58&H^l!U7ZqAisnB42naL
ze?jR36#t++1<C`Ucmbt(P+AA&15i2x<rz@eg3>%Ft%K4yC~bq%G$<{D(l99Pg3>G~
zt$@-fC~bn$Bq)!8(jzGUg7PP*`~jtDP+bM8qd?^;sNMtRDNx-9s-HmR2B<y))p?*g
z6O@KPbtI@>0+p4Zx&jnOpn3;X-+<CBsD1&}E1-H9RNjK>6;Rp$)hVDn3aUduWj?6P
z1Jxm*x&vBgfa?opP@xPh|3PIHsJsW2^Pn^fD%U~fGPEuMrwNdoVBrc17f=|%%m;-J
zEUZCp2E{SR-=MGt#TzJ2LE#9CACNy_?gxbd%q=i`LFobHN08q^{spBGP}&2fH&EIG
z#StiMVc`yo8&DX5;scaMK=BPqN1${8N<Xl)ge~oW(iJGZfx;4$mO*J86c?a)0i^>_
zdI7~NC?H^Q2Z|?9ItGOsDEvTi3`*aybOB4>pnL+#7ohk7#SJLFVR-}=Pss5Ds>?y?
z1QhnLbO}mNu>1r{N1%8H<wsDS1Epb5x&`GgP#OZIXIP#Cr9n_S2c;iSJ_Y43P<;<d
zFQEJeO0Tf=3`%dHv<XWCAipAGP#$VvU|{>lzyOLe1`r=2&(gri6xbon6u375)G7oe
zY>)(~KxtrL5HN?fsX%;?I0FMi10w_LSy1H-ZbpJNfCx4QhI&x7hDq{)q(LQB3TR+H
zzMv>IEwe%|qW~0{P&2_4BLgEN0~j+vb%2Cf86f~7h9m)!WOo*y0E!a^28IjllNY^V
zcNSd$;WIk0JA+a)NEHLa|Nji~Ai2hft&Z!&Kp13IMoMuu*iw+Spd<!LG6D<?T(AEB
z|NozXfm@J)feDlaLBS46(n26JRzsSf0ssF$xWVqsz`zfhb8yZ9&BPY#WhE9t>}N0l
zxrc$3kul0MK*2XW3Y6s-7#JlSUNbO&l6u1b{||StJ4+~l)w6=uD=<R*2qhVqKq;C5
zEC_NS)a#(o00k0Q9O64L304fs;|%3s0}$$<?N(5E0}2sPz67Neki8%egVG%+U4qgr
zC?A0GKFCCneW3gT$}6DuKPZiX5)UXJfYKz$6QHsHl*d7V11e)c`3~d|P?-QKBXH#r
zQ2qer16UaZ3Sdw^1m#Cq8iti8u=EbfGq8LB$~&NZ4$AN7<qIs&!tyD|FW~$K@(?4W
zEdg?41t?HKl3>gN4z%hWg{uxSFr<OXKCtj8G2%j?oQVOP79bvnq>Gvzg{#i||9={k
zHX-7p<VXtva2WzBIG8|X2s@|(K~5-S21k5+aY<qks0~b}0TgQkmHD6q4=Nrp45QR>
zjG$nG1R99MFdwG?2LmH`bVK3){|BI+2v{MsTIL0fM`3SlFoNoHMg|56Mg|5+Mg|5c
zMg|6HMg|5MMg|61Mg|6XMg|52Mg|5&Mg|5YMg|6DMg|5IMg|5|Mg|5oMg|6TMg|5g
zMg|6LMg|6bMg|50Mg|5$Mg|5WMg|5GMg|5mMg|6RMg|58Mg|5;Mg|5eMg|54Mg|5)
zMg|5aMg|5KMg|5~Mg|5qMg|6VMg|5?Mg|5iMg|6NMg|5SMg|67Mg|5yMg|6dMh1oe
zMh1pJMh1ppMh1ouMh1pZMh1p3Mh1p(Mh1omMh1pRMh1o`Mh1pxMh1o$Mh1phMh1pB
zMh1p>Mh1oiM$jTh28JX?28Lut28I+y28L8n<>njg16t*$7ZBjA=aZSl0OCWZdSOBy
zsX00M;rT^5DSF8T(3KQ=MPQZAdXU94aIL|f{-F`bf)II-$rVto=nD%OtP=I|OG_Ah
zGLsZMa|`l|N)!SDoEe-Fb8_<Y^AtQ%a|#%I!xbR2N+6k_)G7wZ;v9wuXMZ<0WL*KS
zC|t-qQ$T<-Z21hzq7IZ9K==$B)b|XKNfpG*9@;D(@*+RDUWgtB^ocZx+u`%e5H5U1
z8D*LaZAuH|bm;UH$j=HWb5I~jjQJ*zAargC#01U#fNAJrCrH34Ko(!3%->j{E%;P`
zL>+@wNornRW-$YV(n~HVV8|^kNrkk?AuNzs1!#FCSQf$pwbzsL^HMTF>wduE2p&kT
z1iZ=yECFSLM2i#CQXyiA#o0NjWvMx6Jh&ndBQr0v1l%zIGeE9LNzKVDOD(F5&rQq&
z>qHR%=}9SxFGwxQ%umToPJ|eaDgsiIUlO03pI4GvQ35sti3^fN(~iUi$rgc^$;Kxq
z=H!4J0b1$`HUyhENPRJedr(EdYBKZEb5cw4^T3|XOD!*sPs~e+Pf5*5ElDi~8xQJE
z6hWNp8|)MBn3EF^i9c}G%!eq-F9sWsoDW{n8=sjE)>>Q=U!0tgno^pRT7)S8vOfh~
z1&RPjMJ_0}CPQ^67L}zIWMo1@*9uf6K==%~`FWWo`A|!e^9xc_;**OqOF%IZUzD1j
znGcDxV(d~Ndx}z%ON)v#%TnVJDGyx?q|ORz70N_8gB3KT<zyx?q*kORmx9tJN>pQt
zf=nwZhJ+u82J!Rrk|C)S%m9g`<rgKV#wRBhL(*d^e8C$yNRYT7#qgYhlqMiCla!g4
z0*)dOBR)4RJ~<h|g|c%~bK}$UU@~c?dC4GOfR({G@g=Fb1v!Z&si>k!iN&ZQ1}O4|
zC_Ez+o-qo~1chgc!ZSnRnWOM5P<WOoJVS_MP?mC_#2$3Up1}%531lW(4-})Q5)dIs
zgcs|AhZ0bPz#MQZVU$3$OF^A{Si=i6I0fpMgTe>YnFe+4L2S^V9H^5IVuJ>pK%IRM
z8#F)%>hy!ypg}fJ=O4rd4a|W$`yh5RXa)nsU|?YA0?ime*)u^S`cU>V&?q~Uy%{t*
z4rOl#jbuaFpb0^cTS46Oh{-;Ndx*(C2GC>;XaEDG<_}`Bj}hb+(0~L30|O&y&;c|s
z0b+v&6F>tLAU0?K5;RZ&VuJ=aK?4>bHfZ1&qzA+X4RnGANkHrp=%5LR4e}#s&;!H<
zO^AR7H9+k7h{-<2)riSH#yyD1K1R@F6LjE~@eX3Lj}bIM0~!PYnFE>x1Pz9O*nbg|
zeN3Ri6wv4sXrdEj25683#0L2bG*|*+g9brBd=MMdL4kHqnLvZEpuu2}IB0+oG?)Tn
zg9bQ3gTo*;Xpj{&xB_B>2HXum0n5O^1e&k|r4NueXmSuV=mKJcCe%QKkRUcFPC<h(
zAodo-WFOOB#AF{6XhI4!I0I4xic?S=fY=WZlYLB}NmWq#15Lt$(k5u|2E+!%Curam
z#0G^EXfOxF2H6jqpa8K!6B8gmgV>+}UT8Og88jFS8bk$&HzFqcm?tA9`<Rz9Fff1y
zd_ihJX%dtsKy1*2FKA#G#0E_~fd+y>Y|tb%Xu<=;ev6pwV+Kt~fd*<pbLSxUgYplE
z4H{$v4RnLpptuDMc!SuW0V~j;G>8o{8#LexVuJ>PAtQtgETG8<kbgkppuumD9Ec5y
zBT!s|*i#r77(fHeAU0^i5tNQW?86KU44?si5c@g<0|RK_9>fNPIcT6C#0I$^H0Tau
z|3pmov4RE#K?BO5No0_lK@%k)HYn|Y(hZ0WN^hWv6A&8|51;{i5F6wdP<a7jgX{<S
z0mKI7DbPSQhz-h9puunu8#b8(V)r2?`&dDffS^eSkT@uffd=nEY|w-tXkq}wKES}h
z0E%M}8#I{?Dw{y;$B4;3R?q|)sGI`LlYrs{6pkP^XuuOR(hFjPCRsoeR3J9UkI?aG
zHc%P_O;CZvLHP(YQ3Yay!V)xL1!9Bz1@aGw4H5%QRDjr^^ah$J0kJ`41!zJG#0E`#
zg9m3B7}!950mUUq{4`>+j}27TfhN2_;-Gwi7^H_}OyWpTH=ZxZ-yfPfAeva+gF>On
zi-DH~)EEIJWH(PAP+v71N{2z|2q+zjq=}CM))oO3=1>JuP&yh)$3W>=C>;l-<Dql{
zlum@wNl-c&N~b{SR4APWr6Z9X!odb<0)Q5NK&7>yv^JCufYO0b+8;?fCv$EhC=GHW
ziE*)|q?RORf|3g_REq?ZmW0w$P+A&F%Rp&aC@l}A6`-^tly-sAu25PDN-INYPblpL
zrB$G`Dw6Yf1agaW6pB&{auSnMb5rw5K<SMYs?ZEdTS93oC~X3zgQ2uJl(vA<Ay8Tk
zN~=R@2Po|brG25aACz{3((X{&2}<ijX#*(j4W)gcv>}u>D$mSIVPIhX%AjU_gyBE~
zCzSt<LCyLNV?u)s18la43+Fr$BuRq?dI-%H!DdxJgHQ~hi~-gP8Y5!hU;+z(W=S9>
zfofmSi~x9E1+JEXfq?@o4>N+3fq@k=z5zCi9Kzn--rg}Fz=wf>u^|Ffn2}=$k{*zG
zNL(yTM$kG4EaGGf;h36&wJ6cdg@qkV7<EbyLlbh~!?cXjq=mr14=Xb;f_7$;=IT+^
zqai@m5D*0yJ&5iwRSh3CY%~OhPza1xt3xQVMx8nu0;3^7lMq1kH%5Gk2o3-yKFFaa
zIho0cpqVGkKnE*>3#0Pj!lR7Q5EwBbFq#KOOjM70bdZL?XdWD-5i{y6x`)7MUZ8uB
zk6JiLLtr#74AO`hbr#)2fCY1VBDxz;w<kijhoY+)<wKVPf|dt@mLP(bcY&5mftD<S
zmJ|*DJ(Osr>Tub3%LqRY1~N$qib&9UG0<jM5Y4lrban0j|8GERPf>CKY*8(W;3#Kg
zg}~@0K%(NC>`j0~nNC|pObiSXObiT?ObiTCObiUtObiS%ObiUNObiV2ObiSPObiT)
zObiT4ObiUlObiSvObiUFObiTaObiU_ObiTKObiU#ObiVAObiSLObiT$ObiT0ObiSr
zObiTWObiU>ObiSbObiT`ObiTGObiSTObiT;ObiT8ObiSzObiUJObiTeObiU}ObiU3
zObiTOObiU(ObiS@ObiUZObiTuObiVEObiSGObiTxObiUcObiSmObiU6ObiTRObiU+
zObiSWObiT>ObiTBObiUsObiS$ObiUMObiThObiV1ObiSOObiT(ObiT3ObiUkObiSu
zObiUE;7zWBY-=dmzDsLH1_m2O1_oP31_nDu1_paB(2_nLM$pk>pnVJYw~#V`4+|3p
z9eM%YO8~0QL5GHcN`24?4WQNcpvnQVGeQEi<&=SeK@v(!L1}5|(Pc8w<I-e7P5>VW
z1~Eq-Dy{$(SA^0^&|}n;p$#q-C|?!o9yKUUa^eQp)2NjbNC<=>J{&$}7O8u4ow4lC
z^<ZF!FH-}B5hT1}J6#~WQ4$&glNY@q`al!ZBnUMCg#y(IpryF5U^j$jB@{)YoRJj*
z;f_I|bGj(=G%Q6?X3D7U(GVEwAuyT~hI$N+x}VYz0ObJ?rqrC_ub&yZ8w%=E-(XMZ
zwpggZC^h0jAfu$Dz)D{~E3qt5uedZ%FF8L~zn~~Tr8K#uSU)QzTi;O6P(LL<xmZ83
zAQQTod{_k%q#Hl1yfo^W(GVC70Ww2?i-7^-5Hd228r3!$0z)wbu$<S#kOMjpV<>ut
z95*vEFhb9)AxHP9o?#XO;6qgSpa)!VL1|7X%@3sopfop>=0Q5)gNe`4FW6JTCo`!i
zu_!YYbiM~OR2eIjW`xpgNZOcreG`*WbTL6y!Dw~`8(+eT7~qB$DX=e`BLG^|0y@r$
zee<O^(CI2jjIn`+>mkfhl7WHaOd9BjAJEZ50$f{9L64t;gbc^&ThQZ>KqrVm#4t%{
zNTcY)R7F?>Y7SwA_*LLMB?OlPsbnvHSHWb-7{dW;LG1T~nS`Lh3K%#*Hyt1Zp)8!C
z0hPx>fv$o;2oo^C0eTk$LIdoIEAYX`NW!#YLVS-fo$#C;LM@1eJWYx-l#vVtEtUZ3
z!--*PVKh#K2nj?WBfAD6PfHd~XOf#QVEK$({jmGSV4lY5K$rsTGz)z30nS)uU_b;s
z%n)Wy<QfcC2f=7|Mka$>6Brm8m`alJK}W(dF&W&N!64AU2<0;~8Qhw~pa7O*`2P)b
zh+<I#jE1`iX4!C~(eon0e~=pp5PWi2Oz@li$kC0WhY@^BAXi>~USe*lUTOu7hCetd
zgOd*nSOb(mF^VvUAKLz42D_iv0d&hCxb>ZrT5OdBy4^kAFy6>C-oPp+GpQJQ9I#aq
z=q&Hi7CPbJ9qKATnFewv00R%`q8ux$;-X}$+{EP3$RFxaOOgAL(gi0XT~K7?sODi1
z0!ZnCi-C!O(aJa2XSApo1`$i47hvha0d%DuI9((r`v)romllAoFBwfC6bA2*)sB=d
zm?8Cu6{OV(YiTl|afhr=M;%T|2q2{k&?W;$D=RB2Xi|XnM@TVlRP8Vc0i<-n2H7A2
z5`k_3876)l^#<i306LX6H!%}>5dr1q4M`I~E30-gFh2HE@MiU1`GM8@^#+JPm>F18
zTPH9ucs!T4@_+yTf{s2&o*_XcpCLvkpCLlQy^O(3Aktr7pCLz|&u=FKqs$Hsd3_d-
zd<GT>U$)KhdO$}+hnj~+fIgR#dVxa`|Dool27N}5YU>%E*FE1b2%+jIU_8*A&SfCH
zAt;@t;NP)^0;U7a=@L@<41Bw^7?{%ePHQnRd1)~)rLh$JJ=UPW%+vsCET(e^=riy&
zYB4YuupDSk=QGe}5ZI8#z>>~V@cURp0mp&nbg58(eIAc21~!ih1~!oW4_pM~(^v|=
zA8TM}@oG-z*t4F2C6D2Mk%GHHv;TVr1E2dbKNRBq-!q8#U6>vp?&|FC7vkv`>K_^$
z91`i{8szBb?g|PW83R!0sO2+ws02s)D`+u<1UKk2=yQYYklCRo&!NS@$`G4oqR$Kt
z8L&7cWR$#|Uoxywx`7E9R)NQmV>q-JSQui`IlyKlq%$StMEcv?Fo@~fv@kJntk|j`
zZ^dAt#jqjN-=0O^riqDxZN*jt`CSg_E~vIy=rizOs9_0i&bi^$oCDfL&uVYOz^8B1
z!ot7<GSz~?)P-RKBoufo^yd4OPK*zC4UY74_V5e!@d*Y600V<Qmr6bZN2tGnJ_Db}
zfeVxL8T7RnSU~=kJ0c)2@4&#P60Z;+<L`H2vb$?Yu&cYTt6zwVXOOFNh^N0FDD1!~
zi%U(PQBNhGQBFUIVVBc-hIvlw85Vi1{g;-;<@l3<(O{0Y$G<d%e1={60-z8CnQtWk
z;%jIyC<M1e`s*`0E!PLz8(p9#4@!}YdI%Byct)*Ie}#O8J^C699P%~{;MDg}NIsrH
zRe||s2goD_CWZh|%My$s$$!L>BI?fmF0Sed>Mo8Uj_L~P0iMnw(EE=@Y?us;$3YjU
zGJrNFgPSj)v<YEAT?6NUE?EU#=EMXM0bi5>Rf9r-E@EY1VDQDE4x$@$0S5yE=!6YF
z9O~d^f-ZDrU|_Jpp$^$R(8XQ0IMgAV2f7T%o(OfIDP9L0>X7YKWB_gChKS$`7tqCC
z-b9!Oy1dN?hdN|`fG*22$Dt158b~;UE_gD-p$^$R&<*WIIMgAV2g<0XIMgAV2fD0G
z4~IHr^FSAw>Elp`Y#wOMxd9G!$mW4AH#5Yc4%s}=#b-J=)FGP(x)e<phdN~QK$oPs
z;!uZd9_V5)HzL%5E>!a%LLKO`HBTJsklkm=06J6v;u7?93K4~*7tkP>KMwPd)q&>y
zw24p$x}Z%9hdN~Ufi8J-AwnJKGPhtH>X6+B+R+k%LmjfcpiAIFai~K!4|MTa7!GyF
z=7BB}i^8D}**wr?a?v={A)5!fXf6haI%M-em(a!HP={<D=z_X99O{tG16^Jhk3$`@
zd7z8!5{OU-x|J*uhdN|?K^NjB;ZTQcFX)22WE|>{%>!MJmV!eavU#A3^-_sY2fFkw
zjR<w1OXSjtPzSoKFM|kmpo{!6iBJdHRh>nII?x4x*+i%VT@IK-ggVg0fw@Ge16?YZ
zM}#`ig@gG-r~|FOD<DE0=%T_xBGiFatP~NU4s^L(F%jxg7#J8zh)@SwUQtSfI?$zw
zWrWnh6E-0RD+4<byBuU8x0n$!j52vpL^>7}fNtlb%pd}~LH79i`he;iyeiSIwa2R#
zm!xli52${@B@Gs*iap`Zpn4H(9<2yaxCI3VIn&B~n7JT(LR=$4^b(7p7jnX6s856K
zNrK)tio<v(&<*MNc?uq>InawkaVW$i47LYUV&GBZ8?NB2@2st@5D<VhjKPw4^n;`z
z_Gp9J)F3WaOg($>dx(1W;16~x+Jo03s@aoTf!7|akw&5*I33_m)(n*T2eft-Vow3s
zKa9;<O^_}G10&ZStt<uxk5?dP6KBtK4zAT#Te$X^ZDCk_wS~iMItSNg2~gjL0d7x0
zGF~4MXAj6l*fD6GE7(5;$r<=^5Y_A<P`U-BR$+H2RFsfBNEz5aplv1~4h|d;;Otlo
zy*3$#5`w}J&i(}JIglDR1<zd2N()?N93hKR@{^$#FcVTqzC5V@DJm|)U$~KPJX|Np
zp5lxgP<s<DhK&*6N@=JuFcg=R(#0N-`}I=tX&QE*jwIL~=#}0eHa1L+^ae6lub=?3
zR2{^j0S2W5kg<9+PIMr9{POca{S1(GxG<xyZvcUk371yl#X*BdUWsLi3O<>6*{L|K
z<Dy4<6I5q`%gKzATv~QM;Pn{jj14?N<r}U53K~2r2up$elMCu95>`uz3K}O_nA5=H
zIeLlsi+(T1AZYD^J3+w=#72YCBuHE@IVZ6gPn}7P_yOCKo{2YtsOF!nM4TB6<PJ*x
z14`E*bM&e*!R<g08ylvEJ&>^qGYfCr1&8zqAFD940F4-9ivR**B#u>(Zx5ZuD*T<i
zKy!F_eeD|%4lOej$o5Zw4^5i~VE2RSZhF*(AbY@d2Z0tGybpvU)TlmIL9spfJw!eK
z;4K0XeQt{V1L<>v69*Q8YW^8)V-;kE8>o%~r)y%z5XiKL<S_(F?ZI2KGcXVuBOoLX
zN?PD>D^5)Zv1y4%c;6mJN+2BKB=+sewg=>r!P2*<M!gO8&oJuSL)yl^sYU5HyZG$G
zt!+%#HW3}l+QfnaoRJ4guhhVxHXc3t?I3%I8Q-LapL`ROGj#nyqsllth9bi)?fd$8
zk}`)42_iBAo5Z<t^6epQuAF>(=+ytDYuSXqdxPkAfI<z+{4&-1YZTjq-$U^J4aN2l
z*<YjF9=sM&%|C;!zeZ-bk=$P+(;kxhYn0kUhc?7;>qmjAEPC`i!ZY)XjT9;@%y2d#
z7(~H+Vf;lCqO7g30Il@~IiF+<u?OEO1O_VFgWp5&vWa5<;4K2F=pQ1-#whhqN-Ey@
z8<Ha(iw1Byz`N>&@^k<%Yw@mnp{6~wjUTvw@{2%gZ?S|b^@PCjL+qF$ndyz>I*L+z
z2rPZ^4Oa-y%%f}_XeMcW7czasz>w+h1lnhTH^TjsvS4#SWZMI>Ko7LS9K^tZk=FTA
zW)HpA*W_g4T{A>A{}5QmL$&zHPs+j(HDF<?*;52Q*coglHUgA+Qj4KU4x0jE#F!Zv
zIKe}G3jU=f#Av`&V{dP74;~X?WMp7Vq;T~S=#EEBD@K$EXye?7^6;o<QA2>m#m7A&
zIXg2YpeR2pJUGA^bm1%_moYFh6!t<-zF-qzVJ&=stev?~o8W2%Wc8zL%0qxT^&`V-
z@Oiaj6BravfOb%V3<a+?V_;wa?Zk#1tPI+b!Caid0a|<tYW1@)E$9dBG;RkS3eV-3
z0%~b4XJBAp3&_k1Vqjo6#=yY9o*0my$-uw>S_RMH>sgY@z`zJPyPC5k2vkEbf_74K
z`KIQTGB7ZLc8zkEIOpdvFfe8_Ffi~q=jW9$Ffg_<Ffj1u7pFQiFfcA<U|`_O%*g?<
zk1#MW@CRq)moqRhK4D;B5b(%M0h#}wfq_BLH@_^Efq@CMLtMx`wZxf$feEyGRXDZ8
zIf#LQ2~-P;RHZuSGcYi9GB7ZR=4680#<Z4!fk6za{xkyvgLsK^NG1aV(=!GJ28oiK
zutWw1X3!<sl9_qVB@7JApq=GX&LuhA3=GVm-L}#>rKy|@49uXJVwoJy;8X?%<~9Zf
z2HB9*VvzbJpp}*kMTzMQ49tfa7#QS3iV~9<7?`hu?jYcCDFT@fJ`I|Ifw6&sfdzDG
zh*DlkY6=4bizz5RGC{^Luz+@SsxU2>`+$Lg1vH)lat8wg14};x0|RImJBYoJfq?-O
zz99Bl1_szc>nxzS&;;4Xz`zQ+_#3oK9TbHiTAOLXbO8niR?w)r4g*_?3IhWxXc9vg
zlqeV&SZf&=81$g**$fN}`jGU%x`hFB<vTb%uwG|iU@(NF2i6}93=Bq)^uQ*`z`$S(
zNe^tGQ2`T3dSC<X{xpT82R2YWZU#vYY`qK&4CavZz_to>LIWf{u$=&%!T?DRY@m3t
zf}{s_HU<U;Ye;%v2c=sZNP1wmXJBBkg`@{|&`wS}Nc^&c{9+GD59}bnI6%?^`yS9~
z29WS)zs<nF-~?6wlYxQ38Im42#26SDTp;Oz1GGcK6_Oq}K=I-RNe>)_3=9nJko3SY
zk%5811Cky%K=I-UNe>(+K|9i2!0CbGIRgWOHzYl9f)11Rfusjc(5VTa9m^9K7&xsN
z7#KjilGzv-I6=EeK|7Bb85lV085kHq`I3u)fpY-^0|RIWF{pjCmw|x+lo$CJ7&z}U
zFff323=1+aaQ<dsU;w#Qgn@wzl*T|if5jOXxIiZYfOhvXF)(m}%m(e?m0@7u0_}~6
z@J_8PW?<j~#Y-du1B(Cy0~aV>qCoo@7#O%f`8^u6n2dpe>oEfZLyR|rQz8QcH^?us
zIRy;93=G^Lzr-;xfocWTM7?}++ijo}2&z?lo%}$1{$R^iLBdqUqisUUgLAY^NO>3z
zWfPe6K*yF0Wgk%J_R&+X-~l*#>J>aFC}c1(Fi3#fL^w`CfVJO2SBZeyU6wf1!Ck?`
zz#v7;sZ~rwo?6Akz#v1+sZ~r23`Ct;#l*ls)TvcW4B#{U2%cKS#K1t*sZ~r244^g(
z!BeZ4Abll*r&cjBFo60b1W&DEVqgHZ=?R`%#RO^Z6Fjww3DOrJcxn|B0|TfZK=9Nm
zCI$x34ts*9RxvR!fQo;Dr&cjBFo61!1W&DEVqgHZQ3;+}#l*ls)TvcW3=Bk_TE)b`
z0P3?4Jhh66fq|$~tC$!VK>Y@Sr&cjBFc5WW6%zvksG&vh)G8(h22g96;Hgzi3=Bk_
zTE)b`0O~6eJhh66fdSM~CwOWV69WUNA5HMoDkcU7&~9sjr&cjBFo62~1W&DEVqgG`
zKM*{%iiv>%G@C;3)G8(h2GAZPf~Qt7F))C}TnL_8#l!&WKQRzIwTcPSKO}f+6%zvk
zsDDTB)G8)OzmnjoRZNgRC&5#zm>_*nf~Qt7LHefzPpx8NU;y=937%TT#J~XR*AhIn
ziiv>%)aNC5Y84X$18CfW;Hgzi3=Bk_TE)b`K-8&KObiS}om$1jzyKQSAb4sO69WTL
zr&cjBFo4Dz2%cKS#K1t*sZ~r244`o(f~Qt7F))DU6bYVM#l*mn#K6En@YE_M1_sbl
z4}zywF)=WJ#xn_?TE)b`09vg~@YE_M1_scWDfLdR8oezH-gX^jV1@vw12B497-qPP
zbP=R<F?w6rNKXt%{zpm|qql`2h0921!qUa)ZDAulC7}8rDP4@-7KR!$BbtYlE=F$)
z8wKzXKuQ;EpxJ-8#3*Al1V%$(WQPD30|VsbhJXNP+&j-kb{LKNeprWqQ+|GNiC#!X
zQEFleo`V;MZx}E#FoGs9hpz`meMV9UjNZzDGq{j;onbl00;e_<2@+4bB;TIlc+$w|
ztsE$6iRve(;7D!6+XI^7MR6hu2fmx1Vta_(%}=>KcrBuue+JvhDP)EleD`|>WS9Nu
ztsIc#PbmMuciDq>6hX9LB?+CFNk|@KDEQO>0u9~KTRA`>g}|T%GlS{Wy3t!X5OD)y
zfi_@)XgvbE`A2W%0EH3)gVOcrtsIE(Kw>e1%gNDOIgo;cI3_*HN$_4?(1zI2TRDh}
z6sRiD0(1~lZ}e6UP%uyxgUZrDdV?t0r*4xtRzbc!bQ-G|y_JLXBo9j0;JOfh*B)_#
z9*$H%s1F2k8N?nUPadS$9{e7H_w6aR2k#I96~hhE=LUr%HcU1D47RZfGUEq6Rzd6u
zdSu!I@7oi5vnQqY&}|H1^i~dR`3#pBs2nBcM0%vYJ&u%s%Lat_=&c-xuppH+oNnBN
ztnC0F)rTt>MsMZ76*73lL3tV6R-r>#J9;Yzo`}FB1v)H!^i~ec079C>h6E9&5`rS5
zw{j2+A`AtfGGp{sjsVbEhA3e}e7}&${u(G%W0}7s-X0?RYn0oA*CKd-jZ%9CTYrsA
z|B&2YBhwy|`)iciLx(oR=&c+mMGjFM(46AvtsK~c3SKr*aF#r{{hW-q2t<sHQEm@j
zi>T(G(OWsNCm0-}@G>2`UI>RWiqiqyp8U~UIdFwBHgR}eIC?7ww%{QsHhL=u!63q_
zfY3S~s@;|`oNnb{V`O9iZT7?(q9ad`<4oEFh_6`%xVD~xEqwqBah$#d>W+ii44_l-
zAuKc!RBJFmPVGaJA&m<)hcr!?szHS@rYIf<QpsMdc47#Uk@CP=KxdR=7zPypD`4Pg
zU|_)X3eM1g>cv8#UU5Od00#z)gdqquQv*uVn1c8oVF~Ou2!sfJ7IM1A8Olh8Dj>13
znhcYN(O4Cs3L*j-*)^zYXvM?nOw7bYoD*P02)X*f=i?$-h0}pZYOpX_Kt~IM#c{?e
z0|O%9!74!n=#~aZ1p&H810*tvM?(M{0*s6d47rJ!d0@^+C72l)7<Mu+KK4`aX7yhA
zfz|sp^u8o!2G-Qp2@DJ#&*iQB-~Yd$qYsj2NKnaVh|$Ssh){4ZV=xnl^w-yC$kFHX
z+sVKvvqM8(pT#4efd#^sZF9UH&=Jw0=HU^b&*h|E;84VWsJW>@pAn?mdWPq9&o>N0
zs5%N54>YH983=C(N@pqfcdVg+=|FS3gp@u5-!3f%rgXm3S`18HS`18SECqj$H7GDM
zH83zRF{E<{=riy&YB4YuupDSk=QGe}5ZI8#z>>~V@cURp0mp&nbg58(eIAc21~!ih
z1~!oW4_pM~(^v|=A8TM}@oG-z*t4F2C6D2Mk%GHHv;TVr1E2dbKNRBq-!q8#U6>vp
z?&|FC7vkv`>K_^$91`i{8szBb?g|PW83R!0sO2+ws02s)D`+u<1UKk2=yQYYklCRo
z&!NS@$`G4oqR$Kt8L&7cWR$#|Uoxywx`7E9R)I^+7!EB47KWH~4zL*s=}ZYZk^c5J
z3}X5=Eldm?E4C`gTQOK@F>DC+w`b9}X<}kvTd~zZewRbK3#x4v`V2f6YFL7sb8dJw
z=YZ~GVYRnm;M2EhVPW6_nQFmc>cX%A5(+#Pdh`8CC&q`n21oiid-#R=_ymIjfPq1u
zOC_IyBh=qOpMlTgz=cWr4EkCOEFgc&9TAY1cVOUCiC2h^@%Oth+1)iH*wx+F)i1=w
zGsx9B#M9po6n5a0#igdtsHc+8D5oF9u*+#Z!#t<;42!(h{!2^aa{S4_XfQ|H<6oLW
zKEp130Z<5n%(oH%@ijCU6oOkK{q>ohmg|G<jV@4=2c<|xJ%osUJfl{qzd}C49(@f4
z4tW~}aO!&~Bp=V9s=)lR17s5DgqYF0{RUSNIJ!H3aK#7RT{C*OAKinTG7CrV_8Yz1
z50ZjdL3etL-tEUQdbb|~sChnmw;$-5($V{#A%z14<Y=3ag1{RFT1Wide(Vg)+$E4h
z+w^iWlTwO7Bx=Nh?kNRfR8b;%qj$=KueBmFv__SUh5+dyz=)JP*%_Dxq4`-iB{iuu
z9h9FTB+OutY7mC;Nuo#d^Jso1DZz{?COHI<^D_gZ1_Of#LvC>i+WKZu4F(1_ka!NN
z`O+Go4pMG$3EC`_rYLA89%2sj3xpm+QG_|j;<8BQAd6esFfcHP6cnYVF?8LS#lXP8
z12M}Aw9uCeBEAnaCCdvH2i*$C0}*dH&cMLH2Neh1CdLO5Us1upz`zd`FJWL{WCM$L
zhl2bJohG(E#=yXM3oPE%caDL9K^UUmb^!weYac{>!a|VSAmYw?3=FIs5b@8Tn;S(T
z;vQxU42%L0@pF$D7#PGL;+}2{4E%Q>;=j8Y7#PGM;*p@+Q;i_v+dwzhfo`p3U|>kS
zz`(%S01>a=%)r0^x}}zZfgwMDfq@wkKHYX8y`WoZ85kJmMlmpOG31sMfZ_{jO@g8Z
z0|O&S9CVf#lDHCRd4xc2NkJy;lop74G(h(J$t}qNozaA(J_&RStwL@|F`D^G77Pq5
zCb=c)ISdTQ@u<iRii_O*5|H^2qrs%PC<6o2fdHT45{7P<FAR`dTp1V`VnP`hm~?Ur
ziZfBokq5a`Bexi24zl_3pj!i>;$VZJM2s&30|Q5HVh+fiP%#jdWXr(7up~DT96lfc
zC{CTjz`&pc4rfVoP&(0sNTh&n*@T3%q<uXD<knYEyzFCOU=RYUmjGQ12)^Z&fq|jr
z3<Cp$6hu6Yoq>Tt2Vzbw=$1T4`jq$&O0&8U@s?){3=EUN>LtTLH{R+&#9Kjb$O4N?
zECE>nx*e8*fgu?bFEU_pZgJ2}gP_}B85kJk8$tdBiz`0`-GmCdZI6M0q4g011K%Eq
z_?5W~klXb@7XYR(Ft9+<r%GEL0|P@k#NM(J1_m~Wf0bu|(o_aSe0dZDgZ>VPIrl+f
z3ysg(0tN;)1+ch^!94~BhAfEsDf1W@n4#iID;XFVvLWKr_c1UqL-L*S)N2e34AA(I
z?_^+LU;&$>{Pj5l14AxEy?ie`Je9v}WME)`mN)Xt85kJsAnIp>@-HZzg2Le`D7}Hj
zReX*yFfc$@l3y2MU|?Pb5%=<7U|=YOn*W)Bf#C*NTzSS?P{2UMZ|z`UU=st2tHgrh
z3Y2dc7#I{zgYrH^++#8W149W!y~2G^9tVpn_wQt2U?_!(e`R1`fRtCtM?rB~1{MDg
zD$~H~RqR3bmP5qVY8V(8PC>+LrZ6xtfb=jhFsOrWaZLh?EAOddU|^_(sDE&dfq~@>
zMEvzp1_lO@90LPGWC#NTqXb0!aVrA@Lp4}EV`Lfw1M>y2xQb;n0|NudK9Kn<KnFB|
z#gz|&Ze*<mt7n*Xgn@wxl5SNLL17C@D<Ji^K!E`*2SDX8L^;C?0i^N=NjxeCsr*3_
zR|CaAto%U|PXMJ~Sown_E)OdIA?2-#{woH^?Xe6D44(wx>0AYzMnJd4f~-7)Nar0#
zKsR@T9m>dZ2cFJVv|lnnZi8iDVC4D$Pv<HOpz;}X`zr$jqtyy{I#>Q|%>cRWm4SiL
z;RGU`3tVM@-0sT2!07w}p3YUmKxJkS*j@%jQ2vFc^D`$HAh*1N!t)m*o$pd+fZXcJ
zz`$S$G82-{ReC|?Jm?lz1_lNzP`w1H*Hl>57#P5}wlXj<y1hfB^9WG=3%aG1fq@|!
z6wZ)zu3`aNS_it7m4SiLYYHNrtIP)_9EdxuK(~HF$^n%oQ27t4Ul|w}tU>7unlEfY
z^&_aRVqjoU1o;t?&Q(}Wf(mkoIo6<6ozV1?2vQ3w%NQ6K;y~pUB%Le2UJnw0sE-Gw
zJxDrNsRz~hpj%QI7#IUq!PB`)5GZb;D?(Eu;pto@3Uu={=oVB42FB27@N}+xIG6!)
j>nQ^RLp&(2=|R%@MNk_9x=r!vE<`$K-Om8I)sz7MA;J(n

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 e391a34f63244dd3207a6cbc0a6498f03ae44b82..f27f0b97b8e1381d3f88de11936d3989c59287df 100644
GIT binary patch
delta 14
WcmaE`i21h6hJIc~g~=0mPXhoiw*}<@

literal 53600
zcmYe!&(C3CU|?ooVANn>IQfBr;j{z;1Dgi}1A{Xo6C(o*IOnINh9?#kW#$(t1Qg|G
zr6!laq(%hooLH2UpQjL9lA_?Ot*zjkpI4lplWG-|nwwves^F5ERGQ9!Lyco;Nxp7L
zVo`c(2`(i8iOJcC>8V8u0f~93Ik;2>=a&{Grz(ULrKT3+QsbDMoLXG05Rh1sfm03G
zwIJJqO7luGb5n7d6#{m%LU3wHNoHO;PUGA%b5a$26AKFPDRL^!%t=vjttcr<#Ay)R
zT@Z_LIm@}UxFkPU!8^6GJijOfr)g#u-U^^p>z<m2%OsEzm(1eC;^NfYq@2_ueCphD
z@{<yC6#NTHGIKMl@T>L7%*)2F0+xkvBpGLYNFvKE$i(9;h^p|!qC9*d@9gGlX5o#?
zYi=O{_!FI1Vp*bsbAE1aVqS`ZPi7v@)B;xMlbDxYnwXAXk#CTfV?hBpMc@u4uyOvS
zB?YB8a}8Jtfsh2Lami1HmsvOh+&3}VKUl#xwJ1Fme{eutq~Mm5h&w|B1UM5)c_1ak
zq&$#1VpASSE&h}TQW4<lhAS<ArJ-dzj&KSHaCR)t#UDgLsa2o^14+8j=urR{5<Z#5
zI3p8eIW)T}_$DT2==$SxCPW1&J>tn|AS0m)@s}v!nR!8=D8rxKDlE(hMJq@NG0_TA
z=US1RT2PXip9d<f@s#=?wZtX?kXrmn0HgvMCpg0woM%8aT6$()Izvfnafua5)dLnm
zsc66=@ZuX*t$;-#A&;m;z=Gh^0IxE@Lg3;6RzZM8;O0S$fH(xD!UZcsu3o_c==B3c
z5Vb@_5`&kYU@^>s04$7>?ZF~wRW?KnDdVFHz!EiF93`E=MKNL;E(48MI3Jp_aR?)a
z87LosvOQcYECIj-5Lp^5f|7wpMC)$UlcOO(R0zO2L@Epn3`|fR?vVZyn3v1Iz`z1#
zF)&PIU|?W{vbQoYFt9<{cNrKM*dc62kXjBXTa$r-ffLI1Wnf_7g0ev!Ep8}#HUk3#
z50t%+fq{V+%6`Vcz`zG#GYK&;Fz`d!CJYP=0#J510|SE~lwHffzyMMQ^2TBY1_oiM
z_(28+1`#Ox5d#B*D1^-nvR@3!Heg_25Qnm(7#J8Nplpztl2G<S1_lNxDEkBh1A{b_
z{gHuzK?cHR0huieWm_;XFvvmK2@DJj@=$gU0|SEsl)a9Dfk6?<KFh$spaf-qU|?WS
zhOk*dZU@B;DCj|EszSxR7#JATplnchszcdx85kHepzLD|3=E(+0O@_hz`&pd5oZI1
zr8bmp&cMK+17#;OFfiys+5HR*40=%ZMg|53eJJ}10|Nsnyg<?ai-Cc`5F*YFibEqP
z8{}_eC>s=CAPh<(o(v2Orcm)11_lN*C_9gVfdS+WkeX%&1_qEnLF}mv3=Eb~HOm+n
z7_6Y|-3$y2)=>6&1_lNjDEl!31A{G;4RV_ugv|kRn>~~b3VR1A8{~FJC>!K9Cn!4}
zG*$p*S28d#xIo#R3=9meQ1$`_1_n1MdpiRI11QfhFfec&VPIeYjWvMSR~Z->K<0wj
z&lwmPKye1qGD?C%0F(zoaRbWppu7%Bm!R?kR3?GS5Kuk`<!?~F29+J4vIkV2fXW(B
z{s!d@P@V(jV^IDD<y%mG1?5vv{sfh0pmYn$pP+mL%A26H3CfG0yaUQJp!5LBgV4MO
z&Ueh9#0||yp!@^MH=z6i$|s=w0m>JkJPAraptK4~)1b5oN|T`U3d#qdv<*u4ptK1}
zlc2N+N`s)Z2TF6GwB`&=Tc9)rN=u+L1WG%gyZ}l!pnL|+N1))MF7^%f0S)}<1q3+j
z`D7+BfcVgME=<THH76%OJijO>MK8Gk+PKy$0;_b^gY>81T7y0PLnDv{A@U%TE1+7@
z$C?<d67}*+OBj4IlN3C23-XIf6aoUA8JrSxa`N-@6g*OM3K)FD6(EBGAeo@lDh5b@
zjUmF>-^~qKSAZ)D7t-nlwG*MuNtE_JN>d-+Du?=>0n*Y$H1JW|_9)GIxL$}J2K1IX
z#O==cuznc0%?@v$qqM=%n%^L&Lwk=PKP#X#u0fI*?P`!9)UzNasC^8kq5WS-z(G5@
zC=FsOv@t*hNYpV{f!faCPD*@9Mp0@aC>0biWaed-=p`2vFcc@IrGgnHiN)DDsb#4-
zU|w>5UP>mY7YOF%mX@SefLTaJRDj0lz=9CzjDi9Ns5FQPkp{64W`TGJdq6y}^&ke=
zK_Es-YEEWZYEfl;ZekwTbQA%QiX!mfW_)sDP7X*BXn;}=mpI6a`6cnm`FSO&6%ZdI
zaY4F@GxO4OQcLplz-FYB#22I%W#*@3CMQBd0#yX014#iI7i3#8h6$)5AT7SZKJkt@
zIq{Gv0_Q$x$mJ%(12HEviNPs9zqmv%1RQS+R!}t{32>yQ!n^9=fI?PW3?2Km!Xl^#
zG5|%K0aY2M0<Z|g`eHqh8=-C~)=dF*$idPuAutD~7GxEajii*iW#Fi3qaiTDLjcs)
z0tEr6tp#c?f!LtF2dE7MVuRW^pf(wZ4Qk_n+F&5IH?)leVuSiOpf(wZods&_f*1@8
z44`>9P<su;1-0uzZ8#9Si-Caw)b<0hXCnH444^hXs4WN*-;C)0F@W0Fptd1M9Mney
zxfR3)wf#ZuLlFBOqW{P69?}0}_=D*GF@oFzYA-S{FffAJh@f^Ohz)Arf!dECHmE%Z
zYDa?DpmrIkJqcomBKm)fsfhj`BdG5MYF~oXfcyw*V}jTd5dA;K`H21><7!0zk8uy8
z|HpU{(f?z-gXsS;K4D;B0JSwiW`g>Kpmr>X{TI>yV*-UMs4WZX`-0lB(EcA2hz7M^
zLE<2Pf&2+#gW8{<_AH1E>XU%lwIFr`qW{N~hUot>6(IV5Ox1|~A5$x$|HlOCFM`^=
zAaiChFfc&dtxQW87#Kk9V37DGME{TJ0HXiLbQ013W4eUs|1p93bD;J#NbeU!|Bo5e
zX8^UeLBkZFumQEPL2Qtnptd%M4QgM5+T0*^00RR9sO=46CowQEfZE_7HYn~uVF6-;
z;tr$-#GZuc|1pEy5AFXkZ$tF|m_cp^wb?=HL49IS+a1KdkLdp~gZkW{c05S@2crMS
z42nBY{s9fGfc)YEO27;ZETFy!Xq*Hj4)V7jR2*csKa>p`p8)v>qz06~0-@p+3=9lG
zP<A&114A&BJ%fRPAq2_>`301YA>4r{LHQBncaT3}{V`Dg2jnM^UqF34P&oneKPX&4
zVFn5ZP+kS)Ur-+p)K3JJRiLpbP&x*s0Z^U=^$kJ!7}S>nrF~FZ0Hpy?dI#luP+14c
z8=!s~DF4995l~qNDicBF94OvF{XGL{83jsnptJ_c@1T4RDu+Pn2b7**{Yp?A!upe-
zaun3B1*K6?*$IkMQ27SR!=Stf>NkSYE2w`9N_(LGAgFu-<xNnY0i_*K9tQO{LFF(g
zy@ARkP<(>o7nBY_<u0gf1od;F`H$#`1^E*c4xsP@X#)8j<Zn<|g7~z=AUoti4q#+p
z&}L*{U}0on;DEA0t2EddK$09m{{A4}!d=4b9ux}lHb{Vx9nz^Q29*zPo<6Q1BcL=3
zk~$7v)Fvwf0~1u0CY07jQq9cilbKYMSd^KHY%WX(D7Zm(BXENl6DSRXT#FE7XaI#N
zD6b_jFtBW6U;rgkhERt85WtYoz|7pU3zVKfdKeiY<8+|7U;r5w1PTaNMvyp2o`C_B
zLqIVO8h(Y?#KZs&ATYtkz)=4mq!5DynZXD$2ds$|6tIk7El}MI3`}54!Geqo3<w*+
z8bFx^#P9-1fh+)H7O)8#J4)A`{QtiZlt{tCqr?ac0Z76EB^^*2fq6cGfdN#(ffKwJ
zLprFQ0_9HzMh2LA$UtZU0|UoT=-9s(10w?mBy0Tt4^CYW(?FRBRDgnLo*kv@?*ISa
zQwNb6B}YR5DFpbTsfG!(@Q;DT0aW5LGBAQ_T_jbb%n=#_paKe1zJOZdppwYSs<<fG
zDmO8CG=YrJ6an!zEL}K&Cb^jy7_EGReMXZ6By2`9iIgsw7{KWQyqq$)v;Z_sHJU<3
zYT7_b7tD})#A-A#jMT({<Zq;O!47VLBFT+1M?+vV1V(NMa3r7m02(O<4Y_e7-vDn-
zgM|i1@-fh)4vafIY0ywFq<an;Tppf&9Q74hApjb0&P~h&EdV7;|FF=+2WmZlmNkP{
z#KadArKV+8fY%hEdJi;$3LT<{>Hx_jF+p5*XYmP;(uUyz`{YG$*quceK=_Of?9QMW
zHIOO>hX4N=<Uw+c5nCPCiGeUEE;3Szv%%JY2K+&>0-6>RU|`^S1sOfz7Gz*x0!=l8
zrlmmBY(gM2RzsFv2mJs4;0C)h0|P&3zm0PaXcuC!URGie#C`??kb4+d85yHI0~CD2
zqagD*j1ms785lrQatZ(cKit9YETI5a&kk}AsLX`8muxaVzPKc@2sG78wh<I+1WoaR
z%0IN2f|yFF<3N);;D!63ek#OB0wid_9-#y@eFGY@{{b2S0k2oaHWbgn1o8lQ1RtC{
zK>9)P!w5DE*<&1Fd5|1P2PXpqD`b%;NC#Qi-rnBcF(AN)fq}6h0<>y?EK?AgK;|KM
z*jS7W*hDE31BC}@))yR7peb%oMg|5o(Ci$tvEZPC%)x;bLgYZIAX6tGK4^{>M8h$X
zO1Ri4gR~GB_%eclakSe=TAYolrg{j7f{H27;xek6JZj)*2n?+d7_C-^R(y@Rb~FS=
zLxB1rfaq_G_!1Eu08D(4!+vrylM_L^+%Q8NtPC!U%7Y7!GDbsS#Du_T9vCrEJ?hax
z8UmwvaF9mKsI%xE0;73>?m<3k;UEox(Y!E7BWBcDbPoZ@EGuLd7PRje>;O;(5ds~7
zhrX%-EQ>^-u4-Ul2AKw)9tW%O4fX_W-37BpiIEus86_nJR{Hu`iDij;#ie<A$@#hZ
z1x5KOrO745`dKO2`i6Rj`YHLz#rlZ_nV=2b!!4M=n?i@1r>O5A(%1A*(G8&T4zwp6
zwC5INENB3jKI=AVzfKBtXaffWBlv(!h5!E_fDUc|`4PM?pMim!7qn)HfjWl{@E{*L
z0NMc!J!?P}N~@82=72rYvLx`K14OU*0(%iQuMdh_m;hvX9Vo^@M@WD~LB~-zFfcGX
zL6?Ksf`W!&=FFKW7^D&x1|62+z`(%v3$z6ndRUAsI9x#oqJr#VU;rKb06Or26|~Hd
zk%57Yk%0kpHUT^61P4Y222Mr>1};Vh25v?M1|CKR2G9ygentic0Y(M}K}H4!Aw~uU
zVMYc95k>|EQAP#^F-8UkaYhCP2}TA6Nk#?+DMkhcX+{PH8Ab*MSw;p1IYx+`3gDG;
z2$zFg1Hv%hBV-V}I6(3c@zK%?5)QaXA{KR`CO&KifyzG6szO+>8^TTj#-?~wY-EH$
zxML9L+#||73rkUynKG(-Gz5lv2#n^0p&o;y?x!>aKzRU!DK%&K>*r!%z&K5N`1^X)
zhod0?4*~F**%)^v!lj2lWArGk;UCAO_>c|MMJGkWuvFXH*x1zC(c0d{QQ-(W_Z4){
zjsRD@dqP`#M_Wr<M_YSaXE#UrmJhA%ot+(>?HwH*y?qn<Cr<32G;v~IUvGa;Uw{9E
z2~(y{o;+pBg#MnMo^Ft2Z|~HpQ>RXzJbBuL{{D#*C-n98_x1Mn_f448*W26M-#>9e
zd1YB?QBffX78Dhime$l(Rh5?&6_=D06%`eimz9<km*nRal~hzzR905i)m7J3*Hlzh
z*VoroSJ%|l*EcrSH`LbFR5#Q&Ha67P)i%^OHZ(OgHrCbF);Be`v^2LgHPqHMHr0Ya
zU0p+CLv4M1Lw#LMb!BBuZBuhyU3FD;RYPNAeO)~$W@~F38W=$4G&VIhHP+U(w$#^E
z*EKdYH8eIgHa0gkHMh5ScD1&)HaE9)c7c4*)7#zC+t<_G-rmvK-P6<C)!EwC($d=8
z*529P)&>fRp5Fex-kz?m_V%u>j*hO*uC|{3zMhV*&d!du-29C6l+?_Ooa~&u+?<@;
z!oq^Q{DOj_{QT_P%&gqpoSck|)Qs$`+}zxPl9Gzb(z3$hqSCU8%F2?`((>w>nwqlm
z;*!$hii+y$s_L@Rit_TZs;Y{z(z5c3nwt8C#-@h)n#!u`^74wx+WPwX>Z+pRf`XEg
z^76{c%F2qWqJpyW>gu|h`nt->($dPZqN1|$s>;gps_L5Rs><@}+N#pBlCo-$;+pc(
z%8IJmrk2*W=H~jky2i%FhPsZnme$tRj*hmrmbRwG=C;PBhT59C+M2q$rl#iRme!V*
zrpDIxj^@_3*4E~h_V$*RmX`MRuHKH;hUU83nwr$Kl;p&ujP%U3tjx5uw9K5`tjzR`
z%&gq(?5vE8w6vVewDeSvL`qtAenCNDVPQ^gQAtTjNl`&zPHt&QMMZg8VL?G*Zb3nQ
zZf<^lSy@?0UVdI~PIi7?QBg%zRaI$mK|x_jMNwH<MMY6@Q9({lR#sL{Q9)r*X=y1q
znH3cm7nT&26qlA37nK$j6@k(LLupA-aY128O;t%zUS2^#Nhw&iw5qDCtg^DatfH){
zro6PQqOrcVwz|5yrm?P}zP7Has;0KOs-mK*y1Klws=ltNxw)aLy0*Hdv8AQ1uCltZ
zzP-J%p}M-Jrnb7gytK5mG%_MGA}S_1F)1N2DLy_nE<Qd!AwE7iEi)rMJuNLYH8DOu
zAt5m#AucvPF)1l6Ju@pWzqlm7ATujFJ0mkYyRf*VD8C>#50qL!0hI;Pn4OuHnVFrH
zot2lDo12}LnVFfDm7boFm7STHnwpxHnwkm<;;gL9Y!JxI$;->m&B@Kq$;!;k&dkdz
z$S*3$&&$cm$;rzr$ji=7Pft(J%`M2!$<77K<mKmsl4xOWZgx&?PJRI>d<yc53JXh%
zL0P$|q^!K6yriVKyt2Byv<w8QE32wXON)yuD=MnWONxq1ic5+Mi}Lewb0Z@oA|j&W
zVk4u%LW6_+gTliiqM{<BVxpsCVxyy@qhew~0T2@(6&(>C85JL&oD`p!o{^rJnvobE
z9hZ`loSL4Nnx2`F0rFXLa!Nu%OiX-AN<v~%N=kBaYHD(FT1r}adU{%Fa&mk^d|X_7
zQgUi?QgUKqVq!u}Vp2+ST53jGT3T9aMn+b8a#Ct)T1t9aI_S)JhV=C89KW3mj1Pt6
z;~7*Hm|u1%<TLC7rw-Z?pwqsEp@aJ((7WP9p*w2Dp!d#+gAPvy-|hxJkc2@JdVif1
zl$M5$G|NEMAto&#Q(^K@aRumPh9Z<!g5G_n3_0YPK?TZJg}O%#L_;TixS=!;loo-~
z0#I5IO7lT!At=ocrG=3ujhOfx{enFekWZ^-hALx)(u`1=4M`g_uWw>9iZ0mM)-akq
z(lLO6odK??NP&If90Bm53=9kk?3*vWf%+UApP;E5(7E`a`5W*Y6C)(Jz>-J==!|dB
zVZaD=DBW*3hY@m@AUi@Gih0QDKoc^W2z78NkgaeI^la@wggWe#5TGNs85kHs5$aIv
zZ3Gz#!i)?IpaU?x5$fPpL8U<ycxDYWp{YxRI?xfv`b4M$O;Z^Vp$-&PdPJxL9qwU>
zLmk8u;0OiZt7t@oI?(AN#zd$C<yI3S)Pc^zHzh(H=<pCTBGiHI4KOD{9q8Tw3mod;
zkqw$^1l>=FLmhJXf$l1>B0?SLJ_BnU>X7XP-9KPMggVf4w=E8J$nFE(U0_FqI?%m&
z_BhlbyARYBcEF(y*<R2+364al1KnxjghL&&y`cLRoQY5ex{tvHhdQ|X7?>CWKu0`+
zF+y}ivP9IK{aswu71UiELmbr=)B`-7LqLV#hztyRdK#X(F)W2#!hj)6k^mEEStCh0
za4Lq>?p%5Kd5O8HdZ`tlE0VA%1~0e)ttbN745P8A!!N|jz)r-7v@GP*ApAyADhs;$
z%CVpTbQ2GyM&Z>Dvd7og2XspeUUg`9Y2sCjOVT&M2Xxa6E@`khRqP3O2Hmg&Hjh>W
zDBOaAgFrXy(8>z1xgdK&Tq8pC5}`d|uqbT^usul`cnwFnL=~?}+>&5>KzBmpR)Tsz
zD;9O&3sA9$BMU+7(FWamge;80M!5$TMFzql-X8oOqMkjVOVc23!$wlk9=sM&&7RZ>
zy!K%8BdKEGbbvouQ=HyFT_cD+1qBRl&wep5a7TeKhv(D?F1Ke53`}`oe-amN!85q5
z6ic|=KD#hjDVDGw44%Ot@azhMz_Sx@dkT{A`iMAtaEBylO(@tu1<4usauC(*fsFIv
zbP(u@W}K3sE9z3K@JWN^!2SVUz6IuCCm^>OW0xaV6m*9)A+;biC>Ki;(tt%iB|o_o
zi!fD%K=n^iaS{H)jS4n`>?zL30o|gA*EF>2xbdpRC0SfjN*8-T_UonO(=_ZLXPq)I
z=;ecK!;Ptt-aw}76%^zX3_OrRGBGF}fVAq-IMIRZ@ypM{(VYOf0E`)ZeFF%TOki~s
z5unZs=ww?3=q>9w4CA6ldlNJ;2QDWwN^)u0`GD7BpiN6SJPZ={4OajK4TwoL2Ky%$
zJc&TI8N_I$agv2O0o-@jOT=IFdpQOvc;<pGl}RNl{esdY$U?nj&~eKk7IsXH_yL)$
zm!63?f~e-7tVF!wL8*U0=^E^xs!VWu55&fXsbLRftisH~8+XAWJ;KK-%q&26`(ld#
z0%9bNRgiBFoyIEsoxDJ!=XibX8xRgHGZe`7Pk;|in+IU`gX(U2)P*2>z;y?K796|}
zgd^05A49;`(_%pMQ7N_uzlW&jAG}2%75!6y*CML<XRwV`keLoZbrd*V6FY`LradH&
zAy8@$-kP0(fqG*Isi5nJ!DSJxh!Nhm$B_~Uhc=0Qd$R2Txn!{P?Ws|3gZ(p%`u32v
zv2SWoI?gUW`*3R;)3r@Rhq5-Ypa5s&fzm5AFsO}3kA6GI9%9Bfso^Kz#N-TJe}#Ym
zXPg~Fk>Qs1eSJJhnZt$z5gCC^;#@iT_K-GLPQE>K>VML;Y{K8YLG(L7p%xH;F^5m}
z{u;&h;P()`e?zf7c)L+l3^yYCYn1wDu=Ur-^bg7XH8SlXxxYrKJ#=V847Yw1sLG;8
zzau;|&)7(z!omz^6M{h$JcfY3XhM`36&7Y7x08b*_7FKXMzKBkJp?anDYl2mvX*jt
z@LEJQ|D>eioxdR`-qH1d(*fR9FGypgWQH5Oti`+Pg_`ydSr=03pZuZ}^zfuM9~?i#
zjwzDqACl`RO6?)A^u;$^Av`mWvUQ-Dr1f3M^brF?roWRHp*Z(X%7V=Sk!=si4!uMW
zi5nxW^QFuldabX?$;7+tg=+pGu#Sgn@sppFg*$c_7^r4XQ7YaQcc9FZS`1Bc_#A{!
z4z!_eCj;YSKLu}A@0A}|y<cyDC}(D1O>LdPz~J#*-pc>|{|h?$AbExam3)R6oqUD}
z1@|%rGl58deSL-;eLm3cQkfkZ^7<?u`3x)&zHFQ0^?;6u4mA&t0DUee^#X??{zJ`8
z4f>2A)z&jSuY0~>5JJ^az<8iJoy$OYLr^+P!M|e-1xyE;(<P+z8TfW-F)*d`oz`Mt
z^3q~pN@FSbd#pi$nW=$+fr%lVLqMN_uThJExq#(Bb2^`aK7+u9EC!ZzmV)2M8VWcL
zG^b02`s?#}WHGRLR4}lC?0?`QAfLuk@cmc=LyK2)I>(;%3@mvJ|BDpd4VwMmGZ^^X
zkNKex@Bf}b#P7oN_;6Qef4>k<zfk|s;NXx*AJ-s9KX+G9=*Sp=LPss1!9yiD(qBP~
zAtbm#pFy7+WQWWSHF*v#23CgHG!uPhaL9ngAt9sW<@}OijnWNF$gqk5G~*n@p~b+$
z5R=XUHX|XODIq7)-`<8nOy8!3iGgFqRt0%01`92Q4Wa(_Ec!N0Obl!*wi?Lqa!7YU
zwar4Gfd@kkOK@|}4X@@L(9S<rdm9EmeVY~*1|E>977V5?3>zS!z+<5|->-CHe7I|H
zq@S~gU#O2yFem^R81%VR@)<Zn{SEXP_&g3=n5563uf@Ou^0(X(0eN``20oQ|h4>hM
zzYCMyT|<Ih-F;pCLR>t9T%AKa{rx~;2ToaBYWj?ND*23Z`aul4oYphUb6U@^$ZPGt
zv@|ZqpA3u!bF@AFrGfS<>kEKF5M;iU0En-l!JrV_66vqc?6h1TY;Sadnmi~)GU_2j
z^y3+|Lj4u;8TROFFmTA*Fo07Z+D>R@1_n;>fVYBwDVf)jgYK{fj|?(0GO#65xCRe&
z;wB^;j#$!a#QJ>H<KPfraq)4FNY2ho2`I|X3J(r&2Av&%$Yl(S428YWx{6JJg|+Yj
zSQnIFF4P8<pitf@MUN0*PW{NRngO(nP;3H&;t3z9o!~W>3=9mQoxred{-AMV=Hd(v
z&=PD=-<O4HK|kn_>UPj^JzS0{p#Ii!1_lPUfXuug1_p*>3=9nHi2?bU3=9mf7#J8h
zd_7B285kHrrwwqH1cBN~jG)c0T)wG!r3?&=o(v2O+$GNWc?=AU*$fN}JkI%fB@7IV
ztqcqdy!pkc&I}BUOBom#_%d^HK<pz73=I6i8TsW542(}07#IXRGE+e2|7T!e5cJJ2
zOJ!hS0_{*1a!)OBW?*1)XJB9uPAzc`VqjnbwFO10Ql0Y|7??U47#KuzGC^)*TFbz|
zAO=-`nt_2qyu>*qlYxQh8R)!=lAN$a1_ox(A?}iydCnya49uzw3=C4vB{|#-49uWw
zDWr2sQ#lzJm_h3$WO6uzQyCbT+ZY%aWJ6MmLF$)))*CYvC8jelFdt@MV2}?fN=#;8
zV7|)0z@Wh6QUo&p8v_G_A_D_s0|NsKsGe8KOG!;(U|=x?#YZN{7zUOQ1_lNdrUi2!
zFfg!yMioKs038a^&%nT-28lzKjSP?z7C_=>85qEawS(B8xX=XI$H2hK#lXOz1yRom
zqP3Y8Oc!8aU<J)B=`gURs4y_Ff~N9xp=xRw7#Q@R?AZ(q4Em7tz`6x=Ksh8muwG|i
zU@(NF2i6}93=Bq)^uQ*`z`$S(Ne^tGu`v@!dSHuSU|=wXqz5)oJ#Gd`4{W^*3=HOw
z^uV@?fq}sSk{;MjfKCg5qz5)oyjVff13Tz65^G3$U<ajJ8%TO!w`X8ru!W=t_80~R
z20KXnvV;6$4@nQ~Aip?3(gXV*1_lO4NcgkgW?*1&f~x<?z`)=PNe>*LlM-AY>4C!n
zbZQ4AJ#c{H#SM}kI0_jU7~CQ0fny>A1A_-7J#c{H#S@YqI8HJ!FnGCu(*wtI1_lOi
zNP6G|ZRz!aqz6vWu6<ty28Ia?44l>s3=DptJjTGl8OOlD;15nu44k0Tqd@tRi-Cc2
z0Rsa=AOi!a<mKE8+A0LfGYkxz_Zb)%f<bwMfr0Zk0|Nudts)EzT%a@-3QFq?3|xi`
z3=CnQL-rXMxIkuyGcYj7FfefCGB7Yic&AntGca(0;w6%Sfkl9UfeREbQJ{6#3=CYL
z{2mQjQpv!;^_YQyA;z1*DUpGJ8|0VRoB{@41_o}BU*Z^;KyG7A)XOKg-3Cg5pjyS(
z$q%&i6}EUABurI2+9sqtI7i!rl!xI^Hi1cRINrcRLX5C8FtC6QKGn-jE^yAzE6&eJ
zRd7x$N&+=>pvHj8GH^c>%x6|$U|<5(iVh465eL9R_=wSdC&OqNgD-)M%26BwjG!C}
zGlfxufq{o1x3~n<@`ee5Iw=|q3@i<~#U*GP2?bYxT9diOC3#4SL7fo|(A7Q=bC_Qs
z<fM_zK^B)sG6z}Q7Tl66C`wIZ=(;fr)N_KEWeb`+<bsIr1NGu~q2eHS^FYKKjze09
zAQ{^_5E~-Cq5{;r0*Nv(*!D0mFtUNgyF)>GL6e4{hV(rK2F6=p@vgpeAP+&*JM3U!
zVC{p5PguynzyNAtGB7Z>xiK)XazMmCgW7GNbICxBUOxr~MgfTUxksQL7{nZ(I0gp(
zI}q{T-H;Y4NG1l<S~Y@*Z;J-?%s`?H45=3w7&sds;?<iO7#Ki34p2k1oq>T_1T5Zd
z2Wo+W&Jkl^V5lu%U|_kCTLM0H2G-*Rb-pwh7#M1DOA0_E`N-m+-kU&fNdc%wi!2W6
z{fOk2<bdWfki?Tf=Y}cdmK1~11CqG1F9QRUOm0bf4g&*nJSv02gfln41Y|zMOJGtF
z)Z;l2;8R?}(CzYtfq?<q+fzNsz`&%FTTq;dYK~F|sJE9}3^E7Vd{t0fXh6il21AJ$
zQ15~xH!%m~PN*1&s{X{lz_27Y5ga}s0VqzL!@$6x1P)J0b5J?~^(Gk@7*aqzU`RMi
z+Jkx|pdKXy14HUQ1_lNpuzHDDkQvYuN?Oi<de0E?G<F6C1|5(j14AunBmt5>CH{lb
zEVTF80_yEe0;`t{2lecsJ<(Q>8?wOS5=%f9KpPy%pmWw_z~Ws0KyCw#R)CxiG6#|l
zInRSeqd>hLP-poo0|QqNSUu;D6`-Cg#63oh3=FK0^vQVy)T1?qi020|Ft9=V%NaM1
zfq}sUBHsFlfkA%<#GHu}K)qXtcxeg)1DgUwJP*{H1oeVJo!p5G49rmRCQ#Zmhp68=
zi-Ca|lJ7VTLGcdiX@cDU4%Cf@nBxQTqa{SW5-7f;pyHq&KeSr30`)lUAmY#WGcYiK
zdXb>P1kkyPd=T-H^$ZLQHV|`mEMQ<@UIr1*^#JvrA>vl=85kIDK*S>}K?MLre2*Ig
z1DhB`{5z;T0rj{+=7anK2_G&=kei|XG-Xh{LDX{zf_lA<5OY*P=^j#Eaf!_Z^}M0t
zpnM2P51b{_K)rB?xHZVGQ($|!L_s}uQ2qgV1Jv720*iA_EC=<@A?gpsFfg#Zfr#Jj
z0~JUR@%Y&c42%*G@mNs#2^uM4U|=}z!N9<L0W8iX0qRME!UAOeXV54JSe)}cs9Xh&
fTrn^(G<h&EFhSj!2ujb;*=HqC8Z*l+MlCl0D!Q_v

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