<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>

<p>Doc. no.&nbsp;&nbsp; N2298=07-0158<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%Y-%m-%d" startspan -->2007-06-21<!--webbot bot="Timestamp" endspan i-checksum="12398" --><br>
Project:&nbsp;&nbsp;&nbsp;&nbsp; Programming Language C++<br>
Reply to:&nbsp;&nbsp; Beman Dawes &lt;bdawes at acm.org&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Peter Dimov &lt;pdimov at pdimov.com&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Herb Sutter &lt;hsutter at microsoft.com&gt;</p>

<h1>Thread-Safety in the Standard Library</h1>
<h2>Introduction</h2>
<p>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.</p>
<h2>Rationale</h2>
<p>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.</p>
<h3>Basic thread-safety guarantee</h3>
<p>Guaranteeing thread-safety for non-shared objects has little or no impact on performance. 
It actually does deliver the promised safety. Thus this basic thread-safety is 
required of implementations.</p>
<h3>Strong thread-safety guarantee</h3>
<p>Guaranteeing thread-safety for 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 
shared objects is not specified, and constraints are put on programs 
accordingly.</p>
<h3>Meaning of <i>thread-safety</i></h3>
<p>Rather than try to define the term <i>thread-safety</i>, the proposed wording 
simple talks about data races and deadlocks. These terms will be defined in the 
core language portion of the standard, and/or are well-know terms of art that do 
not need to be further described in the library clauses.</p>
<h3>Standard library components not given strong guarantee</h3>
<p>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.</p>
<h2>Existing Practice</h2>
<p>As far as is known, the proposed wording reflects existing practice in 
current implementations of the standard library.</p>
<h2>Proposed Wording</h2>
<p><i>Somewhere in [conforming] add a constraint on implementations: </i> </p>
<blockquote>
  <p>Unless otherwise specified, access to different objects of types supplied 
  by the standard library from different threads-of-execution shall not result 
  in a data race or deadlock. </p>
  <p><i>[Note:</i> This  means, for example, that 
  implementations can't use a private static data member in a standard library 
  class without synchronization because it could cause a data race or deadlock even in programs that do 
  not share objects of that class between threads.<i> --end note] </i></p>
  <p>Unless otherwise specified, calls to standard library functions from different threads-of-execution shall not result 
  in a data race or deadlock if the calls do not access non-const objects shared 
  between the threads [constraints].</p>
  <p><i>[Note:</i> This  means, for example, that 
  implementations can't use a static object without synchronization for internal purposes because it could cause a data race or deadlock even in programs that do 
  not explicitly share objects between threads.<i> --end note] </i></p>
</blockquote>
<p><i>Somewhere in [constraints] add a constraint on programs: </i> </p>
<blockquote>
  <p>Unless otherwise specified, access to the same object of a standard library 
  type from different threads-of-execution results in undefined behavior if any 
  of the accesses are via a non-const member function of the object or non-const function 
  parameter of any standard library function, and simultaneous access is not prevented by a standard library 
  supplied locking mechanism ([<i>Editor to supply reference</i>]). </p>
  <p><i>[Note: </i>This lack of strong thread-safety guarantee means that sharing an object of a standard library type between threads 
  without using a locking mechanism may result in a data race, deadlock, or 
  other undesirable behavior. <i>
  --end note]</i></p>
</blockquote>
  <p><i>Add to 19.3 Error numbers [errno] paragraph 1:</i></p>
<blockquote>
  <p> <font color="#228822"><u>A separate <code>errno</code> 
  value shall be provided for each thread-of-execution.</u></font></p>
</blockquote>
  <p><i>Change 20.7 Date and Time [date.time] as indicated:</i></p>
  <blockquote>
  <p>The contents are the same as the Standard C library header <code>&lt;time.h&gt;</code>
  <u>
  <font color="#228822">with the addition of the functions <code>asctime_r</code><span class="q">,
  </span><code>ctime_r</code><span class="q">, </span><code>gmtime_r</code><span class="q">, 
  and </span><code>localtime_r</code><span class="q"> as in the POSIX header
  </span><code>&lt;time.h&gt;</code></font></u>.<sup>229)</sup><font color="#228822"><u>
  </u></font></p>
  <p><font color="#228822"><u>Functions <code>asctime</code><span class="q">,
  </span><code>ctime</code><span class="q">, </span><code>gmtime</code><span class="q">, 
  and </span><code>localtime</code> are not require to be thread-safe 
  ([conforming]).</u></font></p>
  </blockquote>
  <p><i>Change 21.4 Null-terminated sequence utilities [c.strings] as indicated:</i></p>
  <blockquote>
  <p>The contents of these headers shall be the same as the Standard C Library 
  headers &lt;ctype.h&gt;, &lt;wctype.h&gt;,<br>
  &lt;string.h&gt;, &lt;wchar.h&gt;, and &lt;stdlib.h&gt; and the C Unicode TR header &lt;uchar.h&gt;, 
  respectively, with the following<br>
  modifications:</p>
    <p><u><font color="#228822">Header <code>&lt;cstring&gt;</code> includes the 
    functions <code>strerror_r</code><span class="q"> and <code>strtok_r</code> as in the POSIX header
  </span><code>&lt;string.h&gt;</code>.</font></u></p>
    <p><u><font color="#228822">The</font></u><font color="#228822"><u> <code>
    strerror</code> and <code>strtok</code> functions are not require to be 
    thread-safe ([conforming]).</u></font></p>
  <p>The headers shall not define the types char16_t, char32_t, and wchar_t 
  (2.11).</p>
  </blockquote>
  <p><i>Change 26.7 C Library [c.math] paragraph 5 and 6 as indicated:</i></p>
  <blockquote>
    <p>The contents of these headers are the same as the Standard C library 
    headers <code>&lt;math.h&gt;</code> and <code>&lt;stdlib.h&gt;</code> respectively,<br>
    with the following changes:</p>
    <p><u><font color="#228822">Header <code>&lt;cstdlib&gt;</code> includes the 
    function <code>rand_r</code><span class="q"> as in the POSIX header
  </span><code>&lt;stdlib.h&gt;</code>.</font></u></p>
    <p>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>.<u><font color="#228822"> The</font></u><font color="#228822"><u>
    <code>rand</code> function is not require to be thread-safe ([conforming]).</u></font></p>
</blockquote>
  <h2>References</h2>
  <p>
  <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</p>
<hr>
  <p>&nbsp;</p>
<p>&nbsp;</p>

</body>

</html>