<!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>C and C++ Liaison: Compatibility for Atomics</title>
</head>

<body>
<h1>C and C++ Liaison: Compatibility for Atomics</h1>

<p>
ISO/IEC JTC1 SC22 WG14 N1508 - 2010-08-22
<br>
ISO/IEC JTC1 SC22 WG21 N3137 = 10-0127 - 2010-08-22
</p>

<p>
Lawrence Crowl, crowl@google.com, Lawrence@Crowl.org
</p>

<h2>Introduction</h2>

<p>
The draft of
<a href="http://www.open-std.org/JTC1/SC22/WG14/">C1X</a>
includes a facility for atomics.
The primary change in this this facility in the latest draft
<a href="http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1494.pdf">N1494</a>
is incorporation of a
<a href="http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1485.pdf">new
atomics proposal</a>
for a <em>productive</em> syntax
for declaring atomic types and operators for atomic types.
C++0x FCD national body comment CA 23 (and more generally US 1)
requests compatibility between C and C++ with respect to atomics.
</p>

<h2>Issues</h2>

<p>
The concurrency subgroup of WG21
went through the compatibility issues
and in some cases chose a course of action.
When we chose a course of action, it was without objection.
</p>

<h3>Declaration Syntax</h3>

<p>
The central compatibility issue
is a productive syntax for declaring atomic types and objects
that is the same in both C and C++.
</p>

<h4>C++ shall provide an <code>_Atomic(T)</code> macro.</h4>

<p>
The definition would be as follows.
</p>

<blockquote><pre><code>#define _Atomic(T) atomic&lt;T&gt;
</code></pre></blockquote>

<p>
to enable compatible declaration of atomic types and objects.
</p>

<blockquote><pre><code>_Atomic(int) var;
</code></pre></blockquote>

<h4>C++ shall not provide the lower-case <code>atomic</code> macro.</h4>

<p>
An alternative was a lower case macro.
</p>

<blockquote><pre><code>#define atomic(T) atomic&lt;T&gt;
</code></pre></blockquote>

<p>
enabling both declarations
</p>

<blockquote><pre><code>atomic(int) var;
atomic&lt;int&gt; alt;
</code></pre></blockquote>

<p>
However, the committee felt that
such dual use of <code>atomic</code> would be confusing at best.
</p>

<h4>C++ shall not provide an <code>_Atomic</code> type qualifier.</h4>

<p>
The current C draft provides support for
use of <code>_Atomic</code> as a type qualifier.
Such a use would
require considerable change to the C++ standard at a late date
and introduce potential semantic difficulties.
</p>

<p>
The committee discussed recommending that 
C not adopt the qualifier,
but the conversation ended without a conclusion.
</p>

<h3>Free Function/Macro Parameters</h3>

<p>
The free functions/macros currently require
taking the address of the atomic object.
</p>

<blockquote><pre><code>int answer = atomic_fetch_add( &amp;var, 3 );
</code></pre></blockquote>

<h4>
C++ shall not change the atomic object parameters to lvalues.
</h4>

<p>
The consensus was that it was too late in the process
for an essentially unnecessary change.
(Such a change would also require different parameter conventions
for C functions and C macros.)
<p>

<h3>Atomic Type Hierarchy</h3>

<p>
The C++ FCD specifies <code>atomic_int</code>
as a base class of <code>atomic&lt;int&gt;</code>
to enable compatiblity with C parameters.
For example,
</p>

<blockquote><pre><code>extern "C" void some_C_function( atomic_int* arg );
atomic&lt;int&gt; var;
.... { .... some_C_function( &amp;var ); .... } ....
</code></pre></blockquote>

<p>
However, with a productive C syntax,
</p>

<blockquote><pre><code>typedef _Atomic(int) atomic_int;
</code></pre></blockquote>

<p>
would result in a diffent type from the existing C++ <code>atomic_int</code>.
</p>

<h4>C++ shall removed the named types
as bases for the template specializations.</h4>

<p>
This approach ensures type compatibility.
</p>

<h3>Simple Type Names</h3>

<p>
With the introduction of a productive C syntax,
the plethora of simple type names (either struct or typedef)
is no longer necessary.
</p>

<h4>C++ shall remove the simple type names.</h4>

<p>
The feeling was that the standard would be clearer
without the additional names.
</p>

<h3>Non-Integral Operations</h3>

<p>
The current C draft includes support
for arithmetic operations on floating-point types.
The C++ draft does not.
</p>

<h4>C++ shall not support floating-point arithmetic operations.</h4>

<p>
The C++ committee does not know of any compelling use cases for atomic floats.
The C++ committee believes the C standard
under-specifies the effect of atomic floating arithmetic operations
in the presence of floating-point traps.
Therefore, it is prudent and conservative
to not support atomic floating-point arithmetic operations
in the upcoming versions of the standard.
</p>

<h4>The C++ committee recommends that
the C committee not support floating-point operations.</h4>

<p>
In keeping with the discussion above.
</p>

<h3>Headers</h3>

<p>
The original C++ atomics proposal
included a header <code>&lt;stdatomic.h&gt;</code>.
However, the header was later changed to <code>&lt;atomic&gt;</code>
to remove an potentially interference with the C standard.
The C standard has now adopted the <code>&lt;stdatomic.h&gt;</code> header
and the C++ standard must accept it.
</p>

<h4>C++ shall define a <code>&lt;stdatomic.h&gt;</code> header
that provides the atomic types and functions in the global namespace.</h4>

<h4>C++ shall provide the <code>_Atomic</code> macro
in <code>&lt;stdatomic.h&gt;</code> but not in <code>&lt;atomic&gt;</code></h4>

<h4>Open Issue</h4>

<p>
It is an open issue whether
C++ shall provide the atomic type member functions
in <code>&lt;stdatomic.h&gt;</code>.
</p>

<h3>Bitfields</h3>

<p>
The C draft includes support for atomic bitfields.
</p>

<h4>C++ shall not provide atomic bitfields.</h4>

<p>
The C++ definitional template-based approach
is incompatible with atomic bitfields.
</p>

<p>
The C++ committee knows of no use cases requiring atomic bitfields.
Conservatively, then, the languages should not require them.
</p>

<h4>The C++ committee recommends that
the C committee not support atomic bitfields.</h4>

<p>
As per the reasons above.
</p>

<h3>Assignment Operator</h3>

<p>
In C, assignment is used for both initialization and value replacement.
On the other hand,
C++ carefully distinguishes between initialization (construction)
and value replacement (copy assignment).
For implementations of atomics that require a lock internal to the object,
this distinction is critical.
IBM confirms that zOS requires such an implementation.
</p>

<h4>Open Issue</h4>

<p>
Possible resolutions to the above problem
are still under discussion.
</p>

<h3>Access to Members of Atomics</h3>

<p>
C permits access to memberf of an atomic stuct or union.
C++ does not,
one must copy the whole value into and out of the atomic object.
This approach avoids the implementation costs of hierarchical locking.
</p>

<h4>Open Issue</h4>

<p>
Possible resolutions to the above problem
are still under discussion.
</p>

</body>
</html>
