Boost-Commit :

Date view	Thread view	Subject view	Author view

From: bdawes_at_[hidden]
Date: 2007-12-14 08:31:04

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

Log:
V1 issues #20, 21, 27, 28, 31, 33
Text files modified:
   sandbox/committee/LWG/issues.html | 12 ++++++------
   sandbox/committee/LWG/thread_library.html | 31 +++++++++++++++----------------
   2 files changed, 21 insertions(+), 22 deletions(-)

Modified: sandbox/committee/LWG/issues.html
==============================================================================
--- sandbox/committee/LWG/issues.html (original)
+++ sandbox/committee/LWG/issues.html 2007-12-14 08:31:04 EST (Fri, 14 Dec 2007)
@@ -188,7 +188,7 @@
and put the remaining sentences of the first paragraph in their own
paragraph
after this combined paragraph. 
-20. [thread.mutex.class] (30.3.1.1), "effects of m.try_lock(): "It is
+✎ 20. [thread.mutex.class] (30.3.1.1), "effects of m.try_lock(): "It is
undefined behavior:" this isn't idiomatic. The undefinedness attaches
to the
program, not to the code that causes the problem. The correct phrasing
@@ -196,7 +196,7 @@
program that does x, y, or z has undefined behavior" or "The behavior
of a
program that does x, y, or z is undefined." 
-21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. 
+✎ (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. 
22. [thread.timedmutex.requirements] (30.3.2): "To meet the TimedMutex
requirements, types are required to meet the Mutex requirements."
Instad of
@@ -218,8 +218,8 @@
26. [thread.timedmutex.requirements] (30.3.2), effects clause for
timed_lock:
see 24 ("still"), 25. 
-27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. 
-28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. 
+✎ (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. 
+✎ (20) 28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. 
29. [thread.lock.intro] (30.3.3), first paragraph: this would be
clearer in
the singular: "A lock is an object that holds a reference to a mutex and
@@ -231,12 +231,12 @@
The next paragraph talks about a lock owning a mutex; this doesn't fit
the
model that seems to have been used earlier, that a thread owns a mutex. 
-31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. 
+✎ 31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. 
32. [thread.lock.unique] (30.3.3.2), first paragraph: "An object of type
unique_lock is not copyable but is movable." This should be plural:
"Objects
of type unique_lock are not copyable but are movable." 
-33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. 
+✎ 33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. 
34. [thread.lock.unique] (30.3.3.2), requirements clauses: mutex() == 0,
owns_lock() == false; the point of having "exposition only" private
members is

Modified: sandbox/committee/LWG/thread_library.html
==============================================================================
--- sandbox/committee/LWG/thread_library.html (original)
+++ sandbox/committee/LWG/thread_library.html 2007-12-14 08:31:04 EST (Fri, 14 Dec 2007)
@@ -1503,16 +1503,17 @@



-It is undefined behavior:
+The behavior of a program is undefined:


<ul>
-<li>for a thread to call <code>lock()</code> or <code>try_lock()</code> if it
+<li>if a thread calls <code>lock()</code> or <code>try_lock()</code> and the
+thread
already owns the <code>mutex</code> object.
</li>
<li>if a thread terminates while owning a <code>mutex</code> object.
</li>
-<li>to destroy a <code>mutex</code> object owned by any thread.
+<li>if it destroys a <code>mutex</code> object owned by any thread.
</li>
</ul>

@@ -1576,13 +1577,13 @@



-It is undefined behavior
+The behavior of a program is undefined:


<ul>
<li>if a thread terminates while owning a <code>recursive_mutex</code> object.
</li>
-<li>to destroy a <code>recursive_mutex</code> object owned by any thread.
+<li>if it destroys a <code>recursive_mutex</code> object owned by any thread.
</li>
</ul>

@@ -1751,17 +1752,16 @@



-It is undefined behavior:
-
+The behavior of a program is undefined:

<ul>
-<li>for a thread to call <code>lock()</code>,
-<code>try_lock()</code> or either overload of <code>timed_lock</code>
-if it already owns the <code>timed_mutex</code> object.
+<li>if a thread calls <code>lock()</code>,
+<code>try_lock()</code> or either overload of <code>timed_lock</code> and the
+thread already owns the <code>timed_mutex</code> object.
</li>
<li>if a thread terminates while owning a <code>timed_mutex</code> object.
</li>
-<li>to destroy a <code>timed_mutex</code> object owned by any thread.
+<li>if it destroys a <code>timed_mutex</code> object owned by any thread.
</li>
</ul>

@@ -1834,14 +1834,13 @@



-It is undefined behavior
-
+The behavior of a program is undefined:

<ul>
<li>if a thread terminates
while owning a <code>recursive_timed_mutex</code> object.
</li>
-<li>to destroy a <code>recursive_timed_mutex</code> object owned by any thread.
+<li>if it destroys a <code>recursive_timed_mutex</code> object owned by any thread.
</li>
</ul>

@@ -1929,7 +1928,7 @@
<code>lock_guard</code> controls the ownership of a mutex within a scope.
A <code>lock_guard</code> object maintains ownership of a mutex
throughout the <code>lock_guard</code>'s lifetime.
-Behavior is undefined
+The behavior of a program is undefined
if the mutex pointed to by <code><var>pm</var></code>
does not exist for the entire lifetime ([basic.life])
of the <code>lock_guard</code> object.
@@ -2059,7 +2058,7 @@
may be transferred to another <code>unique_lock</code> object.
An object of type
<code>unique_lock</code> is not copyable but is movable.
-Behavior is undefined
+The behavior of a program is undefined
if <code>mutex() != 0</code>
and the mutex pointed to by <code>mutex()</code>
does not exist for the entire remaining lifetime ([basic.life])

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk