Boost-Commit :

Date view	Thread view	Subject view	Author view

From: bdawes_at_[hidden]
Date: 2008-04-25 11:27:25

Next message: kbelco_at_[hidden]: "[Boost-commit] svn:boost r44764 - trunk/boost/config/platform"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r44762 - sandbox/committee/LWG"

Author: bemandawes
Date: 2008-04-25 11:27:25 EDT (Fri, 25 Apr 2008)
New Revision: 44763
URL: http://svn.boost.org/trac/boost/changeset/44763

Log:
Improved Executive Summary, make Basic thread-safety guarantee more explicit, improve Strong thread safety wording, remove "reentrant subroutine" latitude, tighten note wording, tighten allocate/deallocate wording and make both uses consistent, other library functions that call rand must observe thread safety. Thanks to Lawrence for many comments and suggestions.
Text files modified:
sandbox/committee/LWG/thread_safety.html | 77 ++++++++++++++++++++++++---------------
1 files changed, 47 insertions(+), 30 deletions(-)

Modified: sandbox/committee/LWG/thread_safety.html
==============================================================================
--- sandbox/committee/LWG/thread_safety.html (original)
+++ sandbox/committee/LWG/thread_safety.html 2008-04-25 11:27:25 EDT (Fri, 25 Apr 2008)
@@ -41,9 +41,11 @@

Unless otherwise specified, standard library classes may safely
be instantiated from multiple threads and standard library functions are reentrant,
-but objects of standard library types are not safe to share between threads
-if an expression evaluation conflict (N2334)
-occurs, unless protected by a synchronization mechanism..
+but non-const use of objects of standard library types
+is not safe if shared between threads. Use of non-constness
+to determine thread-safety requirements ensures consistent thread-safety
+specifications without having to add additional wording to each and every
+standard library type.
</blockquote>
<h2><a name="Introduction">Introduction</a></h2>
With the introduction of multi-threading into the C++ standard, the contract
@@ -51,30 +53,35 @@
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
-as is possible without impacting performance or creating an illusion of safety
+as is possible without impacting performance or creating an illusion of 
+thread-safety
where none exists.
<h3>Basic thread-safety guarantee</h3>
-Guaranteeing standard library functions be reentrant and guaranteeing thread-safety for
-standard library types has little or no impact on performance.
-It does actually deliver the promised safety. Thus this basic thread-safety is
+Requiring standard library functions be reentrant and
+non-mutating uses of objects of
+standard library types not introduce data races has little or no impact on performance.
+It does actually deliver the promised safety. Thus this basic thread-safety
+guarantee is
required of implementations.
<h3>Strong thread-safety guarantee</h3>
-Guaranteeing thread-safety for mutating shared objects would have a severe negative
+Requiring mutating uses of objects of
+standard library types not introduce data races would have a severe negative
impact on performance. Furthermore, real safety often requires locking across several
member function calls, so providing per function-call locking would
-create a illusion of safety that did in fact not exist. For these reasons, strong thread-safety for
+create a illusion of safety that did in fact not exist. For these reasons, this strong thread-safety
+guarantee for
mutating
shared objects is not provided, and constraints are put on programs
accordingly.
<h3>Meaning of thread-safety</h3>
The proposed wording
talks in terms of data races and expression evaluation conflicts. Data races
-and expression evaluation conflicts will be defined in the core language
+and expression evaluation conflicts are defined in the core language
portion of the standard, so do
not need to be further described in the library clauses.
<h3>Standard library components not given strong guarantee</h3>
Consideration was given to specifying rand function and the global locale
-objects on a per-thread basis. That is not proposed because it does not
+objects on a per-thread basis. That is not required because it does not
represent existing practice. Mac OS X, for example, does not support per-thread
global locale objects.
<h2><a name="Existing-practice">Existing practice</a></h2>
@@ -93,15 +100,23 @@
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),  exceptions (17.4.4.8),
-and
-thread safety ([res.on.thread.safety]).
-</blockquote>
-At the end of [conforming] add a new subsection: 
-<blockquote>
- 17.4.4.9 Thread safety [res.on.thread.safety]
- Unless otherwise specified, calls to standard library functions from
+functions (17.4.4.3), member functions (17.4.4.4), 
+<strike>reentrancy</strike>
+thread safety (17.4.4.5), access specifiers (17.4.4.6), class derivation (17.4.4.7),
+and  exceptions (17.4.4.8).
+</blockquote>
+Change 17.4.4.5 Reentrancy [reentrancy] from: 
+<blockquote>
+17.4.4.5 Reentrancy [reentrancy]
+Which of the functions in the C++ Standard Library are not reentrant
+subroutines is implementation-defined.
+</blockquote>
+To:
+<blockquote>
+ 17.4.4.5 Thread safety [res.on.thread.safety]
+ Unless otherwise specified, C++ Standard Library
+ functions shall be reentrant subroutines.
+ Unless otherwise specified, calls to C++ Standard library functions from
 different threads shall not result in a data race unless
 non-const
 arguments to the calls,
@@ -113,7 +128,8 @@
 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
+Unless otherwise specified, 
+C++ Standard Library
functions shall perform all operations with observable effects solely within the
current thread. 
 
@@ -134,7 +150,8 @@
 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
+ [Note: This <strike>lack of strong thread-safety guarantee</strike>
+ prohibition against concurrent non-const access means that
 modifying an object of a standard library type shared between threads
 without using a locking mechanism may result in a data race<strike> or
 other undesirable behavior</strike>. 
@@ -147,8 +164,8 @@
 <code>delete</code>, and the Standard C library functions <code>calloc</code>,
 <code>malloc</code>, <code>realloc</code>, and <code>free</code> shall
 not introduce data races ([intro.multithread])
- 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,
+ as a result of concurrent calls from different threads. Calls 
+ to these functions 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
 this order.
</blockquote>
@@ -163,10 +180,9 @@
 not introduce data races ([intro.multithread])
 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 <strike>happens</strike>
+ member functions from different threads. Calls
+ to these functions that allocate or deallocate a
+ particular unit of storage shall occur in a single total order, and each such 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:
@@ -197,12 +213,13 @@
 It is implementation defined whether or not the
 <code>rand</code> function is thread-safe ([res.on.thread.safety]).
 Implementations of <code>rand</code> are encouraged
- but not required to provide such thread-safety.
+ but not required to provide such thread-safety. Calls to <code>rand</code>
+ from other library functions shall not result in data races.
</blockquote>
 <h2><a name="Acknowledgements">Acknowledgements</a></h2>
 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.
+ insights that have been reflected in this proposal.
 <h2><a name="Revision-history">Revision history</a></h2>
 N2603 - Revision 2:
 <ul>

Next message: kbelco_at_[hidden]: "[Boost-commit] svn:boost r44764 - trunk/boost/config/platform"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r44762 - sandbox/committee/LWG"

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