[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

Argh.  The accu mailing list seems to drop the decadentplace
mailing list.  Here is a response that should have come to
both lists.

On 5/3/07, Roger Orr <rogero at howzatt.demon.co.uk> wrote:
> I think I'd prefer something like this:
>
> - a C-style atomic type (usable in both C and C++ with the same semantics in
> both)
> - free functions that operate on the C-style type, providing both strong and
> weak operations

This behavior is in N2145.

> - a C++ (SC) atomic class
> - member functions of the atomic class (not yet sure whether they should be
> operators or named members)

N2145 has operators where possible, members otherwise.

> - some explicit conversion between the C++ class and the C type

N2145 has an inheritance relationship.  There is no conversion
though, because atomics are variables, not values.  To move information
from one atomic to another, you load and store contained values.

> I have some concern over the current atomic types proposal in that
> the C and C++ types have different semantics.
>
> // C
> {
>    atomic_int a;
>    atomic_int b;
>    a = b;
> }
>
> // C++
> {
>   std::atomic_int a;
>   std::atomic_int b;
>   a = b; // Error, as op= declared with "= delete" in C++ definition (using
> N2210)
> }

The assignment operator is "wrong" here, and I would eliminate it in C
if I could, but there is simply no mechanism to do so in C99.  I suspect
that if C were to formally adopt the approach, they would outlaw the
assignment.  So, the intended semantics are the same.

> So could we:
> - declare struct atomic_int as a pretty nearly raw struct in both C and C++
> (in std:: here)
> - move all the C++ 'clever stuff' into std::atomic<int> and have that as the
> strong atomic class

We could do that, but then there would be no operator access to types
that are common to both C and C++.  For example:

a.h:   ....  atomic_int x; ....
b.c:   ....  atomic_fetch_add_ordered( &x, 1 ); ....
c.cc:   ....  x += 1; ....

Under N2145, the c.cc code works and is equivalent to the b.c code.
Under what you suggest, C++ programmers would be forced into
writing what is under b.c.  My vague recollection is that people didn't
want that approach.

> - add an explicit conversion operator/accessor to atomic<int> to
> get access to the underlying atomic_int type.

What is your goal in this requirement?  Is it to prevent accidental use
of less-than-fully-ordered operations?  Is it to pass out a reference
for use by C code?

The status in N2145 is that given either atomic_int or atomic<int>,
to access the less-than-fully-ordered operations, one must write the
free function call taking the address as in (1) below.  Wouldn't your
change simply change that to (2) below?

   atomic<int> x;
   atomic_fetch_add_relaxed( &x, 3 ); // 1
   atomic_fetch_add_relaxed( x.underlying(), 3 ); // 2

I really don't think anyone is going to get to either 1 or 2 accidentally.

-- 
Lawrence Crowl