Boost-Commit :

Date view	Thread view	Subject view	Author view

From: bdawes_at_[hidden]
Date: 2008-04-20 21:28:02

Next message: chris_at_[hidden]: "[Boost-commit] svn:boost r44665 - trunk/libs/asio/example/invocation"
Previous message: chris_at_[hidden]: "[Boost-commit] svn:boost r44663 - trunk/boost/asio/detail"

Author: bemandawes
Date: 2008-04-20 21:28:02 EDT (Sun, 20 Apr 2008)
New Revision: 44664
URL: http://svn.boost.org/trac/boost/changeset/44664

Log:
Draft 1 of revision 2 circulated for comment
Text files modified:
sandbox/committee/LWG/thread_safety.html | 84 ++++++++++++++++++++++++++++-----------
1 files changed, 60 insertions(+), 24 deletions(-)

Modified: sandbox/committee/LWG/thread_safety.html
==============================================================================
--- sandbox/committee/LWG/thread_safety.html (original)
+++ sandbox/committee/LWG/thread_safety.html 2008-04-20 21:28:02 EDT (Sun, 20 Apr 2008)
@@ -10,17 +10,21 @@

<body>

-Doc. no.   N2410=07-0270 
+Doc. no.   Nxxxx=08-xxxx 
Date:       
-2007-09-07 
+2008-04-20 
Project:     Programming Language C++ 
Reply to:   Beman Dawes <bdawes at acm.org> 
               
Peter Dimov <pdimov at pdimov.com> 
               
-Herb Sutter <hsutter at microsoft.com>
+Herb Sutter <hsutter at microsoft.com> 
+                Hans Boehm <Hans.Boehm at hp.com> 
+                Lawrence Crowl <crowl at google.com> 
+                Paul E. McKenney <paulmck at linux.vnet.ibm.com> 
+ 

-<h1>Thread-Safety in the Standard Library (Rev 1)</h1>
+<h1>Thread-Safety in the Standard Library (Rev 2)</h1>

Executive summary 
<a href="#Introduction">Introduction</a> 
@@ -42,7 +46,7 @@
</blockquote>
<h2><a name="Introduction">Introduction</a></h2>
With the introduction of multi-threading into the C++ standard, the contract
-between standard library users and implementors needs to explicitly state the
+between standard library users and implementers needs to explicitly state the
conditions under which standard library components are or are not thread-safe.
<h2><a name="Rationale">Rationale</a></h2>
The objective is to offer users of the standard library as much thread-safety
@@ -76,19 +80,18 @@
As far as is known, the proposed wording reflects existing practice in
current implementations of the standard library.
<h2><a name="Proposed-Wording">Proposed Wording</a></h2>
-References shown as ([Multi-threaded executions and data races]) refer to
+References shown as ([Multi-threaded executions and data races]) refer to
the new section of that name described in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm">
-N2334</a> or it successor.
+N2334</a> or it successor.
Change 17.4.4 Conforming implementations [conforming] as indicated:
<blockquote>
This subclause describes the constraints upon, and latitude of,
implementations of the C++ Standard library. The following subclauses describe
an implementation’s use of headers (17.4.4.1), macros (17.4.4.2), global
functions (17.4.4.3), member functions (17.4.4.4), reentrancy (17.4.4.5), access
-specifiers (17.4.4.6), class derivation (17.4.4.7), 
-<strike>and</strike> exceptions (17.4.4.8), and
-thread safety ([res.on.thread.safety]).
+specifiers (17.4.4.6), class derivation (17.4.4.7),  exceptions (17.4.4.8), and
+thread safety ([res.on.thread.safety]).
</blockquote>
At the end of [conforming] add a new subsection: 
<blockquote>
@@ -96,32 +99,48 @@
 Unless otherwise specified, calls to standard library functions from
 different threads shall not result in a data race unless
 arguments to the calls,
- including <code>*this</code>, directly or indirectly access objects shared
+ including <code>*this</code>, directly or indirectly 
+ <strike>access</strike> point to or reference objects shared
 between the threads in such a way that an expression evaluation conflict
 occurs ([Multi-threaded executions and data races]) .
 [Note: This means, for example, that
 implementations can't use a static object for internal purposes without
 synchronization because it could cause a data race even in programs that do
 not explicitly share objects between threads. --end note] 
+Unless otherwise specified, standard library
+functions shall perform all operations with observable effects solely within the
+current thread. 
+ 
+[Note: This allows implementations to parallelize operations if there are
+no visible side effects. --end note]
</blockquote>
Somewhere in [constraints] add a constraint on programs: 
<blockquote>
- Unless otherwise specified, direct or indirect access to the same object of
+ <strike>Unless otherwise specified, direct or indirect access to the same object of
 a standard library type from different threads results in undefined behavior
 if any of the accesses are via a non-const member function of the object or
 non-const argument
- to any standard library function, including <code>*this</code>, and one does
- not happen before the other ([Multi-threaded executions and data races]).
+ to any standard library function, including *this, and one does
+ not happen before the other ([Multi-threaded executions and data races]).</strike>
+ Unless otherwise specified, calls to standard
+ library functions from different threads result in undefined behavior if any
+ non-const arguments, including *this, directly or indirectly point to or
+ reference objects of a standard library type shared between the threads, and
+ one call does not happen before the other ([Multi-threaded executions and data
+ races]).
 [Note: This lack of strong thread-safety guarantee means that
 modifying an object of a standard library type shared between threads
- without using a locking mechanism may result in a data race or
- other undesirable behavior. 
+ without using a locking mechanism may result in a data race<strike> or
+ other undesirable behavior</strike>. 
 --end note]
</blockquote>
 To 18.5.1 Storage allocation and deallocation [new.delete], add:
<blockquote>
- The library versions of operator <code>new</code> and <code>delete</code>
- shall not introduce data races ([Multi-threaded executions and data races])
+ Neither the library versions of operator <code>new</code> and <code>delete</code>,
+ user replacement versions of global replacement operator <code>new</code> and
+ <code>delete</code>, nor the Standard C library functions <code>calloc</code>,
+ <code>malloc</code>, <code>realloc</code>, or <code>free</code> shall
+ <strike>not</strike> introduce data races ([Multi-threaded executions and data races])
 as a result of concurrent calls from different threads. Calls that allocate or
 deallocate a particular unit of storage shall occur in a single total order,
 and each such deallocation call happens before the next allocation (if any) in
@@ -136,10 +155,13 @@
 <blockquote>
 Except for the destructor, member functions of the default allocator shall
 not introduce data races ([Multi-threaded executions and data races])
- as a result of concurrent accesses to default allocator objects from different
+ as a result of concurrent <strike>accesses</strike>
+ calls to default allocator object's
+ member functions from different
 threads. Allocation and deallocation calls that allocate or return a
 particular unit of storage shall occur in a single total order, and each such
- deallocation call happens before the next allocation (if any) in this order.
+ deallocation call <strike>happens</strike>
+ shall occur before the next allocation (if any) in this order.
 </blockquote>
 To 20.7 Date and Time [date.time], add:
 <blockquote>
@@ -157,13 +179,27 @@
 <blockquote>
 The <code>rand</code> function has the semantics specified in the C
 standard, except that the implementation may specify that particular library
- functions may call <code>rand</code>. The
- <code>rand</code> function is not require to be thread-safe ([res.on.thread.safety]).
+ functions may call <code>rand</code>. The
+ <code>rand</code> function is not require to be thread-safe ([res.on.thread.safety]).
</blockquote>
 <h2><a name="Acknowledgements">Acknowledgements</a></h2>
- Hans-J. Boehm provided helpful suggestions for improving the proposed
- wording.
+ Jeffrey Yasskin's, N2519 Library thread-safety
+ from a user's point of view, with wording provided several valuable
+ insights that have been adopted by this proposal.
 <h2><a name="Revision-history">Revision history</a></h2>
+ NXXXX - Revision 2:
+ <ul>
+ <li>Strike "or other undesirable behavior". Data races are the only case we
+ can thing of, so mention them only.</li>
+ <li>Replace uses of "access" with well defined terms, and clarify related
+ wording.</li>
+ <li>Include user supplied global operator new and delete, and the C library
+ memory allocation functions in the prohibition against allocation data
+ races.</li>
+ <li>Specify when library implementation may or may not multithread.</li>
+ <li>Acknowledge N2519.</li>
+ <li>Add additional authors.</li>
+</ul>
 N2410 - Revision 1:
 <ul>
 <li>Provided Executive summary.</li>

Next message: chris_at_[hidden]: "[Boost-commit] svn:boost r44665 - trunk/libs/asio/example/invocation"
Previous message: chris_at_[hidden]: "[Boost-commit] svn:boost r44663 - trunk/boost/asio/detail"

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