[Boost-commit] svn:boost r41754 - sandbox/committee/LWG

From: Lawrence_at_[hidden]
Date: 2007-12-05 14:36:55

Author: crowl
Date: 2007-12-05 14:36:55 EST (Wed, 05 Dec 2007)
New Revision: 41754
URL: http://svn.boost.org/trac/boost/changeset/41754

Log:
Update mutex synchronization wording.

Text files modified: 
   sandbox/committee/LWG/thread_library.html |    23 ++++++++++++-----------                 
   1 files changed, 12 insertions(+), 11 deletions(-)

Modified: sandbox/committee/LWG/thread_library.html
==============================================================================
--- sandbox/committee/LWG/thread_library.html	(original)
+++ sandbox/committee/LWG/thread_library.html	2007-12-05 14:36:55 EST (Wed, 05 Dec 2007)
@@ -1302,8 +1302,8 @@
 
 <dt>Synchronization:</dt>
 <dd>
-This operation synchronizes with ([intro.multithread])
-prior <code>unlock()</code> operations on the same object.
+Prior <code>unlock()</code> operations on the same object
+synchronize with ([intro.multithread]) this operation.
 </dd>
 
 <dt>Throws:</dt>
@@ -1349,22 +1349,23 @@
 An implementation may fail to obtain the lock
 even if it is not held by any other thread.
 [<i>Note:</i>
-This spurious failure is normally uncommon.
+This spurious failure is normally uncommon,
+but allows interesting implementations
+based on a simple <code>compare_swap</code> ([atomics.operations]).
 &mdash;<i>end note</i>]
 </dd>
 
 <dt>Synchronization:</dt>
 <dd>
 If <code>try_lock</code> returns <code>true</code>,
-<code>try_lock</code> synchronizes with ([intro.multithread])
-prior <code>unlock()</code> operations on the same object.
+prior <code>unlock()</code> operations on the same object
+synchronize with ([intro.multithread]) this operation.
 [<i>Note:</i>
-Since a failed <code>try_lock()</code>
-is not an acquire operation ([intro.multithread]),
-the resulting memory visibility rules are weak enough
-to permit potentially interesting
-<code>try_lock()</code> implementations based on
-<code>compare_swap</code> ([atomics.operations]).
+Since <code>lock()</code> does not synchronize with
+a failed subsequent <code>try_lock()</code>,
+the visibility rules are weak enough
+that little would be known about the state after a failure,
+even in the absence of spurious failures.
 &mdash;<i>end note</i>]
 </dd>