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

From: bdawes_at_[hidden]
Date: 2007-12-14 08:46:38

Author: bemandawes
Date: 2007-12-14 08:46:37 EST (Fri, 14 Dec 2007)
New Revision: 42028
URL: http://svn.boost.org/trac/boost/changeset/42028

Log:
V1 issues #19, 21, 27, 28
Text files modified: 
   sandbox/committee/LWG/issues.html         |     8 +++---                                  
   sandbox/committee/LWG/thread_library.html |    45 +++++++++++++++++++-------------------- 
   2 files changed, 26 insertions(+), 27 deletions(-)

Modified: sandbox/committee/LWG/issues.html
==============================================================================
--- sandbox/committee/LWG/issues.html	(original)
+++ sandbox/committee/LWG/issues.html	2007-12-14 08:46:37 EST (Fri, 14 Dec 2007)
@@ -179,7 +179,7 @@
 clause says that the implementation is allowed to fail even if the
 lock isn't
 held. I think this belongs in the effects clause. </p>
-<p>19. [thread.mutex.class] (30.3.1.1), descriptive text: the first
+<p>&#9998;19. [thread.mutex.class] (30.3.1.1), descriptive text: the first
 paragraph
 mixes normative and non-normative text. Separate them. I think I'd
 combine the
@@ -196,7 +196,7 @@
 program that does x, y, or z has undefined behavior&quot; or &quot;The behavior
 of a
 program that does x, y, or z is undefined.&quot; </p>
-<p>&#9998; (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
+<p>&#9998; (19), &#9998; (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
 <p>22. [thread.timedmutex.requirements] (30.3.2): &quot;To meet the TimedMutex
 requirements, types are required to meet the Mutex requirements.&quot;
 Instad of
@@ -218,8 +218,8 @@
 <p>26. [thread.timedmutex.requirements] (30.3.2), effects clause for
 timed_lock:
 see 24 (&quot;still&quot;), 25. </p>
-<p>&#9998; (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
-<p>&#9998; (20) 28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. </p>
+<p>&#9998; (19), &#9998; (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
+<p>&#9998; (19), &#9998; (20) 28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. </p>
 <p>29. [thread.lock.intro] (30.3.3), first paragraph: this would be
 clearer in
 the singular: &quot;A lock is an object that holds a reference to a mutex and

Modified: sandbox/committee/LWG/thread_library.html
==============================================================================
--- sandbox/committee/LWG/thread_library.html	(original)
+++ sandbox/committee/LWG/thread_library.html	2007-12-14 08:46:37 EST (Fri, 14 Dec 2007)
@@ -1491,11 +1491,6 @@
 <p>
 The class <code>mutex</code>
 provides a non-recursive mutex with exclusive ownership semantics.
-It satisfies all the Mutex requirements ([thread.mutex.requirements]).
-It shall be a standard-layout class ([class]).
-</p>
-
-<p>
 If one thread owns the <code>mutex</code> object, attempts by another thread to
 acquire ownership will fail (for <code>try_lock()</code>) or block (<code>for
 lock()</code>) until the first thread has released ownership with a call to
@@ -1503,6 +1498,11 @@
 </p>
 
 <p>
+It satisfies all the Mutex requirements ([thread.mutex.requirements]).
+It shall be a standard-layout class ([class]).
+</p>
+
+<p>
 The behavior of a program is undefined:
 </p>
 
@@ -1547,11 +1547,6 @@
 <p>
 The class <code>recursive_mutex</code>
 provides a recursive mutex with exclusive ownership semantics.
-It satisfies all the Mutex requirements ([thread.mutex.requirements]).
-It shall be a standard-layout class ([class]).
-</p>
-
-<p>
 If one thread owns the <code>recursive_mutex</code> object, attempts by another
 thread to acquire ownership will fail (for <code>try_lock()</code>) or block
 (for <code>lock()</code>) until the first thread has completely released
@@ -1559,6 +1554,11 @@
 </p>
 
 <p>
+It satisfies all the Mutex requirements ([thread.mutex.requirements]).
+It shall be a standard-layout class ([class]).
+</p>
+
+<p>
 A thread that owns a <code>recursive_mutex</code> object
 may acquire additional levels of ownership
 by calling <code>lock()</code> or <code>try_lock()</code>.
@@ -1735,12 +1735,6 @@
 <p>
 The class <code>timed_mutex</code>
 provides a non-recursive mutex with exclusive ownership semantics.
-It satisfies all of the TimedMutex requirements
-([thread.timedmutex.requirements]).
-It shall be a standard-layout class (chapter 9 [class]).
-</p>
-
-<p>
 If one thread owns the <code>timed_mutex</code> object,
 attempts by another thread to acquire ownership
 will fail (for <code>try_lock()</code>)
@@ -1752,6 +1746,12 @@
 </p>
 
 <p>
+It satisfies all of the TimedMutex requirements
+([thread.timedmutex.requirements]).
+It shall be a standard-layout class (chapter 9 [class]).
+</p>
+
+<p>
 The behavior of a program is undefined:</p>
 
 <ul>
@@ -1798,19 +1798,18 @@
 <p>
 The class <code>recursive_timed_mutex</code>
 provides a recursive mutex with exclusive ownership semantics.
-It satisfies all of the TimedMutex requirements
-([thread.timedmutex.requirements]).
-It shall be a standard-layout class (chapter 9 [class]).
-</p>
-
-<p>
 If one thread owns the <code>recursive_timed_mutex</code> object,
 attempts by another thread to acquire ownership
 will fail (for <code>try_lock()</code>)
 or block (for <code>lock()</code> or <code>timed_lock()</code>)
 until the first thread has completely released ownership,
 or the call to <code>timed_lock()</code> times out
-(having failed to obtain ownership).
+(having failed to obtain ownership).</p>
+
+<p>
+It satisfies all of the TimedMutex requirements
+([thread.timedmutex.requirements]).
+It shall be a standard-layout class (chapter 9 [class]).
 </p>
 
 <p>