<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">

<title>Recent Concurrency Issue Resolutions</title>

<style type="text/css">
table { border: 1px solid black; border-spacing: 0px }
caption { font-weight: bold }
th { text-align: left; vertical-align: top;
     padding: 0.5em; border: 1px solid black }
td { text-align: left; vertical-align: top;
     padding: 0.5em; border: 1px solid black }
dt { font-weight: bold; }
ins { background-color: #A0FFA0; }
del { background-color: #FFA0A0; }
</style>
</head>

<body>

<h1>Recent Concurrency Issue Resolutions</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N3278 = 11-0048 - 2011-03-25
</p>

<p>
Submitted to a Candid&nbsp;World
by the Concurrency&nbsp;Subgroup
in Committee&nbsp;Assembled
as edited by Lawrence Crowl.
</p>

<p>
<a href="#Introduction">Introduction</a><br>
<a href="#1176">CWG 1176 editorial C1X</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1176.intro.multithread">1.10 Multi-threaded executions and data races [intro.multithread]</a><br>
<a href="#1177">CWG 1177 editorial C1X</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1177.intro.multithread">1.10 Multi-threaded executions and data races [intro.multithread]</a><br>
<a href="#964">LWG 964 technical CH 1, US 2</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#964.thread.condition.condvarany">30.5.2 Class condition_variable_any [thread.condition.condvarany]</a><br>
<a href="#1364">LWG 1364 technical CH 19</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1364.propagation">18.8.5 Exception propagation [propagation]</a><br>
<a href="#1460">LWG 1457 editorial GB 130; LWG 1460 technical US 154</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1460.atomics.syn">29.2 Header <code>&lt;atomic&gt;</code> synopsis [atomics.syn]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1460.atomics.lockfree">29.4 Lock-free property [atomics.lockfree]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1460.atomics.types.generic">29.5 Atomic types [atomics.types.generic]</a><br>
<a href="#1502">LWG 1502 technical US 195</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1502.futures.state">30.6.4 Shared state [futures.state]</a><br>
<a href="#1507">LWG 1507 technical US 196, US 197, US 199</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1507.thread.mutex.requirements.mutex">30.4.1.2 Mutex types[thread.mutex.requirements.mutex]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1507.thread.condition">30.5 Condition variables [thread.condition]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1507.futures.promise">30.6.5 Class template <code>promise</code>[futures.promise]</a><br>
<a href="#1515">LWG 1515 technical US 208</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1515.futures.state">30.6.4 Shared state [futures.state]</a><br>
<a href="#1526">LWG 1526 technical GB 111</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#1526.support.runtime">18.10 Other runtime support [support.runtime]</a><br>
<a href="#2023">LWG 2023 editorial</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2023.thread.lock.guard">30.4.2.1 Class template lock_guard [thread.lock.guard]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2023.thread.lock.unique">30.4.2.2 Class template unique_lock [thread.lock.unique]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2023.thread.lock.unique.cons">30.4.2.2.1 unique_lock constructors, destructor, and assignment [thread.lock.unique.cons]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2023.thread.lock.unique.locking">30.4.2.2.2 unique_lock locking [thread.lock.unique.locking]</a><br>
<a href="#2024">LWG 2024 editorial</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2023.atomics.types.generic">29.5 Atomic types [atomics.types.generic]</a><br>
<a href="#2025">LWG 2025 editorial</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2025.futures.task.members">30.6.9.1 packaged_task member functions [futures.task.members]</a><br>
<a href="#2034">LWG 2034 technical</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2034.atomics.order">29.3 Order and consistency [atomics.order]</a><br>
<a href="#2037">LWG 2037 technical</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2037.atomics.syn">29.2 Header <atomic> synopsis [atomics.syn]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2037.atomics.types.operations.general">29.6.1 General operations on atomic types [atomics.types.operations.general]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2037.atomics.types.operations.templ">29.6.2 Templated operations on atomic types [atomics.types.operations.templ]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#2037.atomics.types.operations.arith">29.6.3 Arithmetic operations on atomic types [atomics.types.operations.arith]</a><br>
</p>

<h2><a name="Introduction">Introduction</a></h2>

<p>
The following issues have been resolved by the Concurrency Subgroup.
They have changes that are either technical since the issues documents,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html">N3236 C++ Standard Core Language Active Issues, Revision 75</a>
and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3245.html">N3245 C++ Standard Library Active Issues List (Revision R74)</a>
or editorial since the issues documents.
Editorial changes respond to changes in the working draft
since the proposed resolution was written.
</p>

<h2><a name="1176">CWG 1176 editorial C1X</a></h2>

<p>
Change the wording from CWG 1176, which has been incorporated into the draft.
This makes the definition consistent with its uses in both the C and C++ drafts.
</p>

<h3><a name="1176.intro.multithread">1.10 Multi-threaded executions and data races [intro.multithread]</a></h3>

<p>Edit paragraph 7 as follows.</p>

<blockquote><p>
A release sequence <del>from</del> <ins>headed by</ins>
a release operation A on an atomic object M
is a maximal contiguous sub-sequence of side effects 
in the modification order of M,
where the first operation is A and every subsequent operation
either is performed by the same thread that performed
the release or is an atomic read-modify-write operation.
</p></blockquote>

<h2><a name="1177">CWG 1177 editorial C1X</a></h2>

<p>
Change the wording from CWG, which has been incorporated into the draft,
to reflect WG14s sense of grammar.
<p>

<h3><a name="1177.intro.multithread">1.10 Multi-threaded executions and data races [intro.multithread]</a></h3>

<p>Edit the first first bullet of paragraph 10 as follows.

<blockquote>
<ul><li><p>
A performs a release operation on an atomic object M,
and, <del>on</del> <ins>in</ins> another thread,
B performs a consume operation on M
and reads a value written by any side effect
in the release sequence headed by A, or
</p></li></ul>
</blockquote>

<h2><a name="964">LWG 964 technical CH 1, US 2</a></h2>

<h3><a name="964.thread.condition.condvarany">30.5.2 Class condition_variable_any [thread.condition.condvarany]</a></h3>

<p>Add a new paragraph after paragraph 2 as follows.</p>

<blockquote><p>
<ins><i>Throws:</i>
<code>bad_alloc</code> or
<code>system_error</code> when an exception is required (30.2.2).</ins>
</p></blockquote>

<p>Add a new paragraph after paragraph above as follows.</p>

<blockquote><p>
<p><ins><i>Error conditions:</i></ins></p>
<ul>
<li><ins><code>resource_unavailable_try_again</code>
&mdash; if any native handle type manipulated is not available.</ins></li>
<li><ins><code>operation_not_permitted</code>
&mdash; if the thread does not have the privilege
to perform the operation.</ins></li>
</ul>
</blockquote>

<h2><a name="1364">LWG 1364 technical CH 19</a></h2>

<h3><a name="1364.propagation">18.8.5 Exception propagation [propagation]</a></h3>

<p>Add a new paragraph after paragraph 6 as follows.</p>

<blockquote><p>
<ins>For purposes of determining the presence of a data race,
operations on <code>exception_ptr</code>
shall access and modify only the <code>exception_ptr</code> objects themselves
and not the exceptions they refer to.
Use of <code>rethrow_exception</code> on <code>exception_ptr</code> objects
that refer to the same exception object
shall not introduce a data race.
[<i>Note:</i>
if <code>rethrow_exception</code>
rethrows the <strong>same</strong> exception (rather than a copy)
then concurrent access to that rethrown exception object
may introduce a data race.
Changes in the number of <code>exception_ptr</code> objects
that refer to a particular exception do not introduce a data race.
&mdash;<i>end note</i>]</ins>
</p></blockquote>


<h2><a name="1460">LWG 1457 editorial GB 130; LWG 1460 technical US 154</a></h2>

<h3><a name="1460.atomics.syn">29.2 Header <code>&lt;atomic&gt;</code> synopsis [atomics.syn]</a></h3>

<p>Edit the synopsis as follows.</p>

<blockquote><pre><code>
namespace std {
  <i>// 29.3, order and consistency</i>
  enum memory_order;
  template &lt;class T&gt;
  T kill_dependency(T y);

  <i>// 29.4, lock-free property</i>
  <ins>#define ATOMIC_BOOL_LOCK_FREE <i>unspecified</i></ins>
  #define ATOMIC_CHAR_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_CHAR16_T_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_CHAR32_T_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_WCHAR_T_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_SHORT_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_INT_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_LONG_LOCK_FREE <i>unspecified</i>
  #define ATOMIC_LLONG_LOCK_FREE <i>unspecified</i>
  <ins>#define ATOMIC_POINTER_LOCK_FREE <i>unspecified</i></ins>
  
  <i>// 29.5, generic types</i>

  template&lt;class T&gt; struct atomic;
  template&lt;&gt; struct atomic&lt;<i>integral</i>&gt;;
  template&lt;class T&gt; struct atomic&lt;T*&gt;;

  <i>// 29.6.1, general operations on atomic types
  // In the following declarations, </i>atomic_type<i> is either
  // </i>atomic&lt;T&gt;<i> or a named base class for </i>T<i> from
  // Table 145 or inferred from
  // Table 146 </i><ins><i>or from</i> bool</ins><i>.</i> 

  &hellip;
}
</code></pre></blockquote>

<h3><a name="1460.atomics.lockfree">29.4 Lock-free property [atomics.lockfree]</a></h3>

<p>Edit the synopsis as follows.</p>

<blockquote><pre><code>
<ins>#define ATOMIC_BOOL_LOCK_FREE <i>unspecified</i></ins>
#define ATOMIC_CHAR_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_CHAR16_T_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_CHAR32_T_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_WCHAR_T_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_SHORT_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_INT_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_LONG_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
#define ATOMIC_LLONG_LOCK_FREE <i><del>implementation-defined</del><ins>unspecified</ins></i>
<ins>#define ATOMIC_POINTER_LOCK_FREE <i>unspecified</i></ins>
</code></pre></blockquote>

<p>Edit the paragraph 1 as follows.</p>

<blockquote><p>
The <code>ATOMIC_&hellip;_LOCK_FREE</code> macros
indicate the lock-free property of the corresponding atomic types,
with the signed and unsigned variants grouped together.
The properties also apply to the corresponding <ins>(partial)</ins> 
specializations of the <code>atomic</code> template.
A value of 0 indicates that the types are never lock-free.
A value of 1 indicates that the types are sometimes lock-free.
A value of 2 indicates that the types are always lock-free.
</p></blockquote>

<h3><a name="1460.atomics.types.generic">29.5 Atomic types [atomics.types.generic]</a></h3>

<p>Edit paragraph 2 as follows.</p>

<blockquote><p>
The semantics of the operations on specializations of <code>atomic</code>
are defined in 29.6 [atomics.types.operations].
</p></blockquote>

<p>Edit paragraph 3 as follows.</p>

<blockquote><p>
Specializations <ins>and instantiations</ins>
of the <code>atomic</code> template
shall have a deleted copy constructor, 
a deleted copy assignment operator,
and a <code>constexpr</code> value constructor.
</p></blockquote>

<p>Edit paragraph 3 as follows.</p>

<blockquote><p>
There <del>are</del> <ins>shall be</ins> full specializations
<del>over</del> <ins>for</ins> the integral types <del>(</del>
<code>char</code>, <code>signed char</code>, <code>unsigned char</code>,
<code>short</code>, <code>unsigned short</code>, <code>int</code>, 
<code>unsigned int</code>, <code>long</code>, <code>unsigned long</code>,
<code>long long</code>, <code>unsigned long long</code>, 
<code>char16_t</code>, <code>char32_t</code>,
<ins>and</ins> <code>wchar_t</code>,
and any other types needed
by the typedefs in the header <code>&lt;cstdint&gt;</code><del>)</del>
on the <code>atomic</code> class template.
For each integral type integral,
the specialization <code>atomic&lt;<i>integral</i>&gt;</code>
provides additional atomic operations appropriate to integral types.
<del>[Editor's note: I'm guessing that
this is the correct rendering of the text in the paper;
if this sentence was intended to impose a requirement,
rather than a description, it will have to be changed.]</del>
<ins>There shall be a specialization <code>atomic&lt;bool&gt;</code>
which provides the general atomic operations
as specified in 29.6.1 [atomics.types.operations.general].</ins>
</p></blockquote>

<p>Edit paragraph 5 as follows.</p>

<blockquote><p>
The atomic integral specializations
and the specialization <code>atomic&lt;bool&gt;</code>
shall have standard layout.
They shall each have a trivial default constructor and a trivial destructor.
They shall each support aggregate initialization syntax.
</p></blockquote>

<p>Edit paragraph 6 as follows.</p>

<blockquote><p>
There <del>are</del> <ins>shall be</ins> pointer partial specializations
<del>on</del> <ins>of</ins> the <code>atomic</code> class template.
These specializations shall have
trivial default constructors and trivial destructors.
</p></blockquote>

<p>Edit paragraph 7 as follows.</p>

<blockquote><p>
There <del>are</del> <ins>shall be</ins> named types
corresponding to the integral specializations of <code>atomic</code>,
as specified in Table 145.
<ins>In addition,
there shall be named type <code>atomic_bool</code>
corresponding to the specialization <code>atomic&lt;bool&gt;</code>.</ins>
Each named type is
<ins>either</ins> a typedef to the corresponding specialization 
or a base class of the corresponding specialization.
If it is a base class,
it shall support the same member functions as the corresponding specialization.
</p></blockquote>

<p>Edit paragraph 8 as follows.</p>

<blockquote><p>
There <del>are</del><ins>shall be</ins> atomic typedefs
corresponding to the typedefs in the header <code>&lt;inttypes.h&gt;</code> 
as specified in Table 146.
</p></blockquote>

<h2><a name="1502">LWG 1502 technical US 195</a></h2>

<h3><a name="1502.futures.state">30.6.4 Shared state [futures.state]</a></h3>

<p>Edit paragraph 10 as follows.</p>

<blockquote><p>
<del>Accesses to the same shared state conflict (1.10).</del>
<ins>Accesses to the result of the same shared state may conflict (1.10).
[<i>Note:</i>
This explicitly specifies that the result of the shared state
is visible in the objects that reference this state
in the sense of data race avoidance ([res.on.data.races]).
For example, concurrent accesses through references returned by
<code>shared_future::get()</code> [futures.shared_future])
must either use read-only operations
or provide additional synchronization.
&mdash;end note</i>]</ins>
</p></blockquote>

<h2><a name="1507">LWG 1507 technical US 196, US 197, US 199</a></h2>

<h3><a name="1507.thread.mutex.requirements.mutex">30.4.1.2 Mutex types[thread.mutex.requirements.mutex]</a></h3>

<p>Edit paragraph 5 as follows.</p>

<blockquote><p>
The implementation shall provide lock and unlock operations,
as described below.
<del>The implementation shall serialize those operations.</del>
<ins>For purposes of determining the existence of a data race,
these behave as atomic operations (1.10 [intro.multithread]).
The lock and unlock operations on a single mutex
shall appear to occur in a single total order.
[<i>Note:</i>
this can be viewed as the modification order (1.10 [intro.multithread])
of the mutex.
&mdash;<i>end note</i>]</ins>
[<i>Note:</i>
Construction and destruction of an object of a mutex
type need not be thread-safe;
other synchronization should be used to ensure that
mutex objects are initialized and visible to other threads.
&mdash;<i>end note</i>]
</p></blockquote>

<h3><a name="1507.thread.condition">30.5 Condition variables [thread.condition]</a></h3>

<p>After the Effects paragraph 7, add a new paragraph as follows.</p>

<blockquote><p>
<ins><i>Synchronization:</i>
The call to <code>notify_all_at_thread_exit</code>
and the completion of the destructors
for all the current thread's variables of thread storage duration
synchronize with (1.10 [intro.multithread])
calls to functions waiting on <code>cond</code>.</ins>
</p></blockquote>

<h3><a name="1507.futures.promise">30.6.5 Class template <code>promise</code>[futures.promise]</a></h3>

<p>After paragraph 1, insert new paragraph as follows.</p>

<blockquote><p>
<ins>The <code>set_value</code>, <code>set_exception</code>,
<code>set_value_at_thread_exit</code>,
and <code>set_exception_at_thread_exit</code> member functions
behave as though
they acquire a single mutex associated with the promise while
updating the promise.</ins>
</p></blockquote>

<p>Delete synchronization clauses of paragraph 17.</p>

<blockquote><p>
<del><i>Synchronization:</i>
calls to <code>set_value</code> and <code>set_exception</code>
on a single promise object are serialized.
[<i>Note:</i>
And they synchronize and serialize with other functions
through the referred shared state.
&mdash;<i>end note</i>]</del>
</p></blockquote>

<p>Delete synchronization clauses of paragraph 21.</p>

<blockquote><p>
<del><i>Synchronization:</i>
calls to <code>set_value</code> and <code>set_exception</code>
on a single promise object are serialized.
[<i>Note:</i>
And they synchronize and serialize with other functions
through the referred shared state.
&mdash;<i>end note</i>]</del>
</p></blockquote>


<h2><a name="1515">LWG 1515 technical US 208</a></h2>

<h3><a name="1515.futures.state">30.6.4 Shared state [futures.state]</a></h3>

<p>Add a new paragraph after paragraph 9 as follows.</p>

<blockquote><p>
<ins>Some functions, e.g. <code>promise::set_value_at_thread_exit()</code>,
delay making the shared state ready until the calling thread exits.
The destruction of each of that thread's
thread storage duration [3.7.2, basic.stc.thread] objects
is sequenced before making that shared state ready.</ins>
</p></blockquote>

<h2><a name="1526">LWG 1526 technical GB 111</a></h2>

<h3><a name="1526.support.runtime">18.10 Other runtime support [support.runtime]</a></h3>

<p>After paragraph 5 add a new paragraph as follows.</p>

<blockquote>
<ins>A call to the <code>setlocale</code> function
may introduce a data race
with other calls to the <code>setlocale</code> function
or with calls to functions that are affected by the current C locale.
The implementation shall behave as if no library function
other than <code>locale::global()</code>
calls the <code>setlocale</code> function.</ins>
</blockquote>


<h2><a name="2023">LWG 2023 editorial</a></h2>

<h3><a name="2023.thread.lock.guard">30.4.2.1 Class template lock_guard [thread.lock.guard]</a></h3>

<p>Remove paragraph 2.</p>

<blockquote><p>
<del>The supplied <code>Mutex</code> type
shall meet the <code>Lockable</code> requirements (30.2.5.3).</del>
</p></blockquote>

<h3><a name="2023.thread.lock.unique">30.4.2.2 Class template unique_lock [thread.lock.unique]</a></h3>

<p>
The intent (in paragraphs 1-3) is to make <code>BasicLockable</code>
the fundamental requirement for <code>unique_lock</code>.
We also update the note to reflect these changes
and synchronize one remaining reference of 'mutex'
by the proper term 'lockable object'
in sync to the wording changes of <code>lock_guard</code>
</p>

<p>Edit paragraph 1 as follows.</p>

<blockquote><p>
...
The behavior of a program is undefined
if the contained pointer <code>pm</code> is not null
and the <del>mutex</del> <ins>lockable object</ins>
pointed to by <code>pm</code>
does not exist for the entire remaining lifetime (3.8)
of the <code>unique_lock</code> object.
The supplied <code>Mutex</code> type
shall meet the <code>BasicLockable</code> requirements (30.2.5.2).
<del>[Editor's note:
BasicLockable is redundant,
since the following additional paragraph requires Lockable.]</del>
</p></blockquote>

<p>Remove paragraph 2 as follows.

<blockquote><p>
<del>The supplied <code>Mutex</code> type
shall meet the <code>Lockable</code> requirements (30.2.5.3).</del>
</p></blockquote>

<p>Edit paragraph 3 as follows.</p>

<blockquote><p>
[<i>Note:</i>
<code>unique_lock&lt;Mutex&gt;</code>
meets the <code><ins>Basic</ins>Lockable</code> requirements.
If <ins><code>Mutex</code>
meets the <code>Lockable</code> requirements
([thread.req.lockable.req]),
<code>unique_lock&lt;Mutex&gt;</code>
also meets the <code>Lockable</code> requirements
and if</ins> <code>Mutex</code>
meets the <code>TimedLockable</code> requirements (30.2.5.4),
<code>unique_lock&lt;Mutex&gt;</code> also meets
the <code>TimedLockable</code> requirements.
&mdash; <i>end note</i> ]
</p></blockquote>

<h3><a name="2023.thread.lock.unique.cons">30.4.2.2.1 unique_lock constructors, destructor, and assignment [thread.lock.unique.cons]</a></h3>

<p>
Add the now necessary
member-wise additional constraints for <code>Lockable</code>.
</p>

<p>Edit paragraph 8 regarding
<code>unique_lock(mutex_type&amp; m, try_to_lock_t)</code>
as follows.</p>

<blockquote><p>
<i>Requires</i>:
<ins>The supplied <code>Mutex</code> type
shall meet the <code>Lockable</code> requirements
([thread.req.lockable.req]).</ins> 
If <code>mutex_type</code> is not a recursive mutex
the calling thread does not own the mutex.</ins>
</p></blockquote>

<h3><a name="2023.thread.lock.unique.locking">30.4.2.2.2 unique_lock locking [thread.lock.unique.locking]</a></h3>

<p>
Add the now necessary
member-wise additional constraints for <code>Lockable</code>.
</p>

<p>Add a new paragraph after the <code>try_lock</code> declaration
and before paragraph 4 as follows.</p>

<blockquote><p>
<ins><i>Requires</i>:
The supplied <code>Mutex</code> type
shall meet the <code>Lockable</code> requirements
([thread.req.lockable.req]).</ins> 
</p></blockquote>

<h2><a name="2024">LWG 2024 editorial</a></h2>

<p>Change 29.5 [atomics.types.generic] p. 6 as indicated:</p>

<h3><a name="2023.atomics.types.generic">29.5 Atomic types [atomics.types.generic]</a></h3>

<p>Edit paragraph 6 as follows.</p>

<blockquote><p>
There are pointer partial specializations
on the <code>atomic</code> class template. These specializations shall have 
<ins>standard layout,</ins> trivial default constructors<ins>,</ins>
and trivial destructors.
<ins>They shall each support aggregate initialization syntax.</ins>
</p></blockquote>

<h2><a name="2025">LWG 2025 editorial</a></h2>

<h3><a name="2025.futures.task.members">30.6.9.1 packaged_task member functions [futures.task.members]</a></h3>

<p>Rename parameter other to rhs in the move constructor.</p>

<blockquote><p>
<code>packaged_task(packaged_task&amp;&amp; <del>other</del> <ins>rhs</ins>) noexcept;</code>
</p></blockquote>

<p>Rename parameter other to rhs in paragraph 5.</p>

<blockquote><p>
<i>Effects:</i>
constructs a new <code>packaged_task</code> object
and transfers ownership of <code><del>other</del> <ins>rhs</ins></code>'s
shared state to <code>*this</code>,
leaving <code><del>other</del> <ins>rhs</ins></code> with no shared state.
</p></blockquote>

<p>Rename parameter other to rhs in paragraph 6.</p>

<blockquote><p>
Postcondition: <code><del>other</del> <ins>rhs</ins></code> has no shared state.
</p></blockquote>

<p>Rename parameter other to rhs in the move assignment operator.</p>

<blockquote><p>
<code>packaged_task&amp; operator=(packaged_task&amp;&amp; <del>other</del> <ins>rhs</ins>);</code>
</p></blockquote>

<p>Edit paragraph 7 as follows.</p>

<blockquote><p>
<i>Effects</i>:
</p>
<ul>
<li><p>
releases any shared state (30.6.4)
</p></li>
<li><p>
<code>packaged_task(<ins>std::move(</ins><del>other</del> <ins>rhs)</ins>).swap(*this)</code>.
</p></li>
</ul>
</blockquote>


<h2><a name="2034">LWG 2034 technical</a></h2>

<h3><a name="2034.atomics.order">29.3 Order and consistency [atomics.order]</a></h3>

<p>Edit paragraph 3 as follows.</p>

<blockquote>
<p>
There shall be a single total order <var>S</var>
on all <code>memory_order_seq_cst</code> operations,
consistent with the &quot;happens before&quot; order
and modification orders for all affected locations,
such that
each <code>memory_order_seq_cst</code> operation <ins><var>B</var></ins>
that loads a value <ins>from an atomic object <var>M</var></ins>
observes <del>either</del> <ins>one of the following values:</ins>
</p>
<ul>
<li>
<ins>the result of</ins> the last <del>preceding</del> modification
<del>according to this order</del> <ins><var>A</var> of <var>M</var>
that precedes <var>B</var> in</ins> <var>S</var>,
<ins>if it exists,</ins> or
</li>
<li>
<ins>if <var>A</var> exists,</ins>
the result of <del>an operation</del> <ins>some modification of <var>M</var>
in the visible sequence of side effects with respect to <var>B</var></ins>
that is not <code>memory_order_seq_cst</code>
<ins>and that does not happen before <var>A</var>, or</ins>
</li>
<li>
<ins>if <var>A</var> does not exist,
the result of some modification of <var>M</var>
in the visible sequence of side effects with respect to <var>B</var>
that is not <code>memory_order_seq_cst</code>.</ins>
</li>
</ul>
<p>
[<i>Note:</i> .... &mdash;<i>end note</i>]
</p>
</blockquote>

<p>
Note that the bullet list is introduced by this change.
</p>

<h2><a name="2037">LWG 2037 technical</a></h2>

<p>Explicitly permit free functions.</p>

<h3><a name="2037.atomics.syn">29.2 Header <atomic> synopsis [atomics.syn]</a></h3>

<p>Edit within the header <code>&lt;atomic&gt;</code> synopsis as follows.</p>

<blockquote><pre>
<i>// 29.6.1, general operations on atomic types</i>
<i>// In the following declarations, <em>atomic-type</em> is either</i> 
<i>// </i><code>atomic&lt;T&gt;</code><i> or a named base class for</i> <code>T</code><i> from</i>
<i>// Table 145 or inferred from</i>
<i>// Table 146.</i>
<ins><i>// If it is </i><code>atomic&lt;T&gt;</code><i>, then the declaration is a template
// declaration prefixed with</i> <code>template &lt;class T&gt;</code></ins>

<del>template &lt;class T&gt;</del>
bool atomic_is_lock_free(const volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*);
<del>template &lt;class T&gt;</del>
bool atomic_is_lock_free(const <var><del>atomic_type</del><ins>atomic-type</ins></var>*);
<del>template &lt;class T&gt;</del>
void atomic_init(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
void atomic_init(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
void atomic_store(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
void atomic_store(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
void atomic_store_explicit(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T, memory_order);
<del>template &lt;class T&gt;</del>
void atomic_store_explicit(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T, memory_order);
<del>template &lt;class T&gt;</del>
T atomic_load(const volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*);
<del>template &lt;class T&gt;</del>
T atomic_load(const <var><del>atomic_type</del><ins>atomic-type</ins></var>*);
<del>template &lt;class T&gt;</del>
T atomic_load_explicit(const volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, memory_order);
<del>template &lt;class T&gt;</del>
T atomic_load_explicit(const <var><del>atomic_type</del><ins>atomic-type</ins></var>*, memory_order);
<del>template &lt;class T&gt;</del>
T atomic_exchange(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
T atomic_exchange(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T);
<del>template &lt;class T&gt;</del>
T atomic_exchange_explicit(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T, memory_order);
<del>template &lt;class T&gt;</del>
T atomic_exchange_explicit(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T, memory_order);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_weak(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_weak(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_strong(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_strong(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_weak_explicit(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T,
  memory_order, memory_order);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_weak_explicit(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T.
  memory_order, memory_order);
<del>template &lt;class T&gt;</del>
bool atomic_compare)exchange_strong_explicit(volatile <var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T,
  memory_order, memory_order);
<del>template &lt;class T&gt;</del>
bool atomic_compare_exchange_strong_explicit(<var><del>atomic_type</del><ins>atomic-type</ins></var>*, T*, T,
  memory_order, memory_order);
  
<i>// 29.6.2, templated operations on atomic types</i>
<del><i>// In the following declarations, <var>atomic_type</var> is either
// </i><code>atomic&lt;T&gt;</code><i> or a named base class for</i> <code>T</code><i> from
// Table 145 or inferred from
// Table 146.</i></del>

template &lt;class T&gt;
T atomic_fetch_add(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_add(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_add_explicit(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_add_explicit(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_sub(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_sub(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_sub_explicit(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_sub_explicit(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_and(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_and(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_and_explicit(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_and_explicit(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_or(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_or(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_or_explicit(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_or_explicit(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_xor(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_xor(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T);
template &lt;class T&gt;
T atomic_fetch_xor_explicit(volatile <del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);
template &lt;class T&gt;
T atomic_fetch_xor_explicit(<del><var>atomic-type</var></del><ins>atomic&lt;T&gt;</ins>*, T, memory_order);

<i>// 29.6.3, arithmetic operations on atomic types</i>
<ins><i>// In the following declarations, <var>atomic-integral</var> is either 
// </i><code>atomic&lt;T&gt;</code> <i>or a named base class for</i> <code>T</code> <i>from 
// Table 145 or inferred from 
// Table 146.
// If it is</i> <code>atomic&lt;T&gt;</code><i>,
// then the declaration is a template specialization declaration prefixed with
//</i> <code>template &lt;&gt;</code></ins>

<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_add(volatile <var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_add(<var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_add_explicit(volatile <var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_add_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_sub(volatile <var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_sub(<var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_sub_explicit(volatile <var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_sub_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_and(volatile <var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_and(<var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_and_explicit(volatile <var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_and_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_or(volatile <var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_or(<var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_or_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_or_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_xor(volatile <var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_xor(<var>atomic-integral</var>*, <var>integral</var>);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_xor_explicit(volatile <var>atomic-integral</var>*, <var>integral</var>, memory_order);
<del>template &lt;&gt;</del>
<var>integral</var> atomic_fetch_xor_explicit(<var>atomic-integral</var>*, <var>integral</var>, memory_order);
</pre></blockquote>

<h3><a name="2037.atomics.types.operations.general">29.6.1 General operations on atomic types [atomics.types.operations.general]</a></h3>

<p>Edit paragraph 1 as follows.</p>

<blockquote><p>
The implementation shall provide
the <ins>functions and</ins> function templates
identified as &quot;general operations on atomic types&quot;
in 29.2 [atomics.syn].
</p></blockquote>

<p>Edit paragraph 2 as follows.</p>

<blockquote><p>
In the declarations of these <ins>functions and function</ins> templates,
the name <em>atomic-type</em> refers to either <code>atomic&lt;T&gt;</code>
or to a named base class for <code>T</code>
from Table 145 or inferred from Table 146.
</p></blockquote>

<h3><a name="2037.atomics.types.operations.templ">29.6.2 Templated operations on atomic types [atomics.types.operations.templ]</a></h3>

<p>Delete paragraph 2 as follows.</p

<blockquote><p>
<del>In the declarations of these templates,
the name <em>atomic-type</em> refers to
either <code>atomic&lt;T&gt;</code>
or to a named base class for <code>T</code>
from Table 145 or inferred from Table 146.</del>
</p></blockquote>

<h3><a name="2037.atomics.types.operations.arith">29.6.3 Arithmetic operations on atomic types [atomics.types.operations.arith]</a></h3>

<p>Edit paragraph 1 as follows.</p>

<blockquote><p>
The implementation shall provide
the <ins>functions and</ins> function template specializations
identified as &quot;arithmetic operations on atomic types&quot;
in 29.2 [atomics.syn].
</p></blockquote>

<p>Edit paragraph 2 as follows.</p>

<blockquote><p>
In the declarations
of these <ins>functions and function</ins> template specialization<ins>s</ins>, 
the name <em>integral</em> refers to an integral type
and the name <em>atomic-integral</em> 
refers to either <code>atomic&lt;</code><em>integral</em><code>&gt;</code>
or to a named base class for <em>integral</em>
from Table 145 or inferred from Table 146.
</p></blockquote>

</body>
</html>
