Boost-Commit :

Date view	Thread view	Subject view	Author view

From: bdawes_at_[hidden]
Date: 2008-04-20 20:45:54

Next message: chris_at_[hidden]: "[Boost-commit] svn:boost r44662 - in trunk: boost/asio/detail libs/asio/doc"
Previous message: hartmut.kaiser_at_[hidden]: "[Boost-commit] svn:boost r44660 - trunk/libs/spirit/doc/lex"

Author: bemandawes
Date: 2008-04-20 20:45:54 EDT (Sun, 20 Apr 2008)
New Revision: 44661
URL: http://svn.boost.org/trac/boost/changeset/44661

Log:
Initial commit - N2410 - pre-Kona
Added:
sandbox/committee/LWG/thread_safety.html (contents, props changed)

Added: sandbox/committee/LWG/thread_safety.html
==============================================================================
--- (empty file)
+++ sandbox/committee/LWG/thread_safety.html 2008-04-20 20:45:54 EDT (Sun, 20 Apr 2008)
@@ -0,0 +1,196 @@
+<html>
+
+<head>
+<meta http-equiv="Content-Language" content="en-us">
+<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
+<meta name="ProgId" content="FrontPage.Editor.Document">
+<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
+<title>Thread-Safety in the Standard Libary</title>
+</head>
+
+<body>
+
+Doc. no.   N2410=07-0270 
+Date:       
+2007-09-07 
+Project:     Programming Language C++ 
+Reply to:   Beman Dawes <bdawes at acm.org> 
+               
+Peter Dimov <pdimov at pdimov.com> 
+               
+Herb Sutter <hsutter at microsoft.com>
+
+<h1>Thread-Safety in the Standard Library (Rev 1)</h1>
+
+Executive summary 
+Introduction 
+Rationale 
+Existing practice 
+Proposed wording 
+Acknowledgements 
+Revision history 
+References
+
+<h2><a name="Executive-summary">Executive summary</a></h2>
+<blockquote>
+
+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..
+</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
+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
+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
+required of implementations.
+<h3>Strong thread-safety guarantee</h3>
+Guaranteeing thread-safety for mutating shared objects 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
+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
+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
+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>
+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
+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.
+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]).
+</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
+ different threads shall not result in a data race unless
+ arguments to the calls,
+ including <code>*this</code>, directly or indirectly access 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] 
+</blockquote>
+Somewhere in [constraints] add a constraint on programs: 
+<blockquote>
+ 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]).
+ [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. 
+ --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])
+ 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
+ this order.
+</blockquote>
+ To 19.3 Error numbers [errno] paragraph 1, add:
+<blockquote>
+ A separate <code>errno</code>
+ value shall be provided for each thread-of-execution.
+</blockquote>
+ To 20.6.1 The default allocator [default.allocator], add:
+ <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
+ 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.
+ </blockquote>
+ To 20.7 Date and Time [date.time], add:
+ <blockquote>
+ Functions <code>asctime</code>,
+ <code>ctime</code>, <code>gmtime</code>,
+ and <code>localtime</code> are not require to be thread-safe ([res.on.thread.safety]).
+ </blockquote>
+ To 21.4 Null-terminated sequence utilities [c.strings], add:
+ <blockquote>
+ Functions <code>
+ strerror</code> and <code>strtok</code> are not require to be
+ thread-safe ([res.on.thread.safety]).
+ </blockquote>
+ Change 26.7 C Library [c.math] paragraph 5 and 6 as indicated:
+ <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]).
+</blockquote>
+ <h2><a name="Acknowledgements">Acknowledgements</a></h2>
+ Hans-J. Boehm provided helpful suggestions for improving the proposed
+ wording.
+ <h2><a name="Revision-history">Revision history</a></h2>
+ N2410 - Revision 1:
+ <ul>
+ <li>Provided Executive summary.</li>
+ <li>Simplified wording.</li>
+ <li>Added wording to cover both direct (i.e. shallow) and indirect (i.e. deep)
+ access.</li>
+ <li>Removed mention of deadlocks as unnecessary.</li>
+ <li>Added expression evaluation conflict wording as more precise, and well
+ defined by the Multi-threaded executions and data races wording from
+ N2334.</li>
+ <li>Added strong exception safety for the default allocator.</li>
+ <li>Struck *_r functions from proposal.</li>
+</ul>
+ N2298 - Initial version.
+ <h2><a name="References">References</a></h2>
+ 
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm">
+ N2334</a>, Concurrency memory model (revised again), Clark Nelson and Hans-J.
+ Boehm
+ 
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1947.pdf">
+ N1947</a>, The Memory Model and the C++ Library, Non-Memory Actions etc., Nick
+ Maclaren
+<hr>
+  
+ 
+
+</body>
+
+</html>
\ No newline at end of file

Next message: chris_at_[hidden]: "[Boost-commit] svn:boost r44662 - in trunk: boost/asio/detail libs/asio/doc"
Previous message: hartmut.kaiser_at_[hidden]: "[Boost-commit] svn:boost r44660 - trunk/libs/spirit/doc/lex"

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