[cpp-threads] RE: volatile, memory models, threads

[Peter Dimov]

Boehm, Hans wrote:
> Herb -
>
> I think the discussion has always been based on the assumptions that
>
> a) There will be some sort of atomics library, or possibly language
> support.  You need this to get access to primitives like fetch-and-add
> or compare-and-swap. [...]


> b) There may or may not be a type qualifier to support simple use of
> atomics.  This would be sufficient for double-checked-locking and
> similar idioms, which seem moderately common in end-user code. [...]

My opinion on encouraging DCL aside... there is a missing link between (a) 
and (b), and it is the actual declaration of the atomic data.

One option is to specify:

    template<class T> T atomic_increment( T * pt );

and leave the set of valid arguments implementation-defined (usually a 
correctly aligned integral type.) It's been my intention to try to produce a 
proposal along these lines, but unfortunately I got swamped with other work.

But there is some opposition to just leaving the "atomic domain" (the set of 
objects that can be manipulated via the atomic operations library) 
implementation defined. The main objections are:

A. if the library operates on ordinary ints, it will be too easy to use 
non-atomic operations on these ints;

B. if the library operates on ordinary data, it will be possible to invoke 
an atomic operation on data that does not meet the necessary prerequisites 
(alignment, placement, isolation).

So... we might need to somewhat constrain the atomics library to only 
operate on objects that have been tagged as atomic.

We can express this tagging as

    atomic<T> a;

or as

    atomic T a;

and in the latter case we have the options of

1. making "atomic" a storage specifier (&a is T*, which doesn't really solve 
the objections above, but makes it possible for the compiler to warn on some 
suspect uses)

or

2. making "atomic" a (non cv-) qualifier that can't be added implicitly, can 
be casted away relatively safely, and can possibly be added via a cast 
relatively unsafely.

In the latter case, we now have an atomic_increment:

    template<class T> T atomic_increment( T atomic * pt );

that addresses the objections above, but we still need to define what an 
"atomic int" or an "atomic X", where X is a POD, means. In particular, what 
does

    x1 = x2;

mean when one or both of x1 and x2 is atomic, and how do the implicitly 
generated copy constructor and assignment operator of X operate when one or 
both of the argument and *this is atomic. Which brings us to (b).