<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1460: Missing lock-free property for type bool should be added</title>
<meta property="og:title" content="Issue 1460: Missing lock-free property for type bool should be added">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1460.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#Resolved">Resolved</a> status.</em></p>
<h3 id="1460"><a href="lwg-defects.html#1460">1460</a>. Missing lock-free property for type <code>bool</code> should be added</h3>
<p><b>Section:</b> 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.lockfree">issues</a> in [atomics.lockfree].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-154</b></p>

<p>There is no <code>ATOMIC_BOOL_LOCK_FREE</code> macro.</p>

<p>Proposed resolution suggested by the NB comment:</p>

<p>
Add <code>ATOMIC_BOOL_LOCK_FREE</code> to 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> and to 32.5.2 <a href="https://wg21.link/atomics.syn">[atomics.syn]</a>:
</p>
<blockquote><pre>
[..]
<ins>#define ATOMIC_BOOL_LOCK_FREE <em>unspecified</em></ins>
#define ATOMIC_CHAR_LOCK_FREE <em>unspecified</em>
#define ATOMIC_CHAR16_T_LOCK_FREE <em>unspecified</em>
#define ATOMIC_CHAR32_T_LOCK_FREE <em>unspecified</em>
[..]
</pre></blockquote>


<p><i>[2011-03-12: Lawrence comments and drafts wording]</i></p>


<p>Point: We were missing a macro test for <code>bool</code>.</p>

<p>Comment: The <code>atomic&lt;bool&gt;</code> type is the easiest to make lock-free.
There is no harm in providing a macro.</p>

<p>Action: Add an <code>ATOMIC_BOOL_LOCK_FREE</code>.</p>

<p>Point: We were missing a macro test for pointers.</p>

<p>Comment: The national body comment noting the missing macro
for <code>bool</code> did not note the lack of a macro for pointers because
<code>ATOMIC_ADDRESS_LOCK_FREE</code> was present at the time of the comment.
Its removal appears to be an overzealous consequence of removing
<code>atomic_address</code>.</p>

<p>Action: Add an <code>ATOMIC_POINTER_LOCK_FREE</code>.</p>

<p>Point: Presumably <code>atomic_is_lock_free()</code> will be an inline function
producing a constant in those cases in which the macros are useful.</p>

<p>Comment: The point is technically correct, but could use some
exposition. Systems providing forward binary compatibility, e.g.
mainstream desktop and server systems, would likely have these
functions as inline constants only when the answer is true.
Otherwise, the function should defer to a platform-specific dynamic
library to take advantage of future systems that do provide lock-free
support.</p>

<p>Comment: Such functions are not useful in the preprocessor, and not
portably useful in <code>static_assert</code>.</p>

<p>Action: Preserve the macros.</p>

<p>Point: The required explicit instantiations are <code>atomic&lt;X&gt;</code> for each
of the types <code>X</code> in Table 145. Table 145 does not list <code>bool</code>, so 
<code>atomic&lt;bool&gt;</code> is not a required instantiation.</p>

<p>Comment: I think specialization was intended in the point instead of
instantiation. In any event, 32.5.8 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> paragraph 5 does
indirectly require a specialization for <code>atomic&lt;bool&gt;</code>.  Confusion
arises because the specialization for other integral types have a
wider interface than the generic <code>atomic&lt;T&gt;</code>, but 
<code>atomic&lt;bool&gt;</code> does not.</p>

<p>Action: Add clarifying text.</p>

<p>Point: The name of Table 145, "atomic integral typedefs", is perhaps
misleading, since the types listed do not contain all of the
"integral" types.</p>

<p>Comment: Granted, though the table describe those with extra operations.</p>

<p>Action: Leave the text as is.</p>

<p>Point: The macros correspond to the types in Table 145, "with the
signed and unsigned variants grouped together". That's a rather
inartful way of saying that <code>ATOMIC_SHORT_LOCK_FREE</code> applies to
<code>signed short</code> and <code>unsigned short</code>. Presumably this also means that
<code>ATOMIC_CHAR_LOCK_FREE</code> applies to all three char types.</p>

<p>Comment: Yes, it is inartful.</p>

<p>Comment: Adding additional macros to distinguish signed and unsigned
would provide no real additional information given the other
constraints in the language.</p>

<p>Comment: Yes, it applies to all three <code>char</code> types.</p>

<p>Action: Leave the text as is.</p>

<p>Point: The standard says that "There are full specializations over the
integral types (<code>char</code>, <code>signed char</code>, ...)" <code>bool</code> 
is not in the list. But this text is not normative. It simply tells you 
that "there are" specializations, not "there shall be" specializations, which would
impose a requirement. The requirement, to the extent that there is
one, is in the header synopsis, which, in N3242, sort of pulls in the
list of types in Table 145.</p>

<p>Comment: The intent was for the specializations to be normative.
Otherwise the extra member functions could not be present.</p>

<p>Action: Clarify the text.</p>

<p><i>[Proposed Resolution]</i></p>

<blockquote>
<ol>
<li><p>Edit header <code>&lt;atomic&gt;</code> synopsis 32.5.2 <a href="https://wg21.link/atomics.syn">[atomics.syn]</a>:</p>

<blockquote><pre>
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;]
}
</pre></blockquote>
</li>

<li><p>Edit the synopsis of 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> and paragraph 1 as follows:</p>

<blockquote><pre>
<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>
</pre><blockquote>
<p>
1 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></blockquote>  
</li>

<li><p>Edit 32.5.8 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> paragraph 3, 4, and 6-8 as follows:</p>

<blockquote><p>
2 The semantics of the operations on specializations of <code>atomic</code> are defined in 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a>.
<p/>
3 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/>
4 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  [atomics.types.operations.general].</ins>
<p/>
5 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/>
6 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/>
7 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/>
8 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>
</li>
</ol>
</blockquote>


<p id="res-1460"><b>Proposed resolution:</b></p><p>
Resolved 2011-03 Madrid meeting by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3278">N3278</a>
</p>




</body>
</html>
