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. </p>
-<p>20. [thread.mutex.class] (30.3.1.1), "effects of m.try_lock(): "It is
+<p>✎ 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." </p>
-<p>21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
+<p>✎ (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
<p>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 @@
<p>26. [thread.timedmutex.requirements] (30.3.2), effects clause for
timed_lock:
see 24 ("still"), 25. </p>
-<p>27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
-<p>28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. </p>
+<p>✎ (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
+<p>✎ (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: "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. </p>
-<p>31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. </p>
+<p>✎ 31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. </p>
<p>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." </p>
-<p>33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. </p>
+<p>✎ 33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. </p>
<p>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 @@
</p>
<p>
-It is undefined behavior:
+The behavior of a program is undefined:
</p>
<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 @@
</p>
<p>
-It is undefined behavior
+The behavior of a program is undefined:
</p>
<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 @@
</p>
<p>
-It is undefined behavior:
-</p>
+The behavior of a program is undefined:</p>
<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 @@
</p>
<p>
-It is undefined behavior
-</p>
+The behavior of a program is undefined:</p>
<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])