[cpp-threads] Re: Weak vs Strong Atomics

[Roger Orr]

cpp-threads-bounces at decadentplace.org.uk wrote:

> I haven't made a proposal beyond N2145 yet.  I wanted to
> tease out the requirements and goals first.

Agreed.  Here's my take ...

Goal: to provide a (slightly!) safer subset of the atomics which we can
encourage most C++ programmers to stick to.

We agreed in Oxford that we wanted an SC atomics class in C++ and a separate
weak atomic class.
Tentatively to be called atomic<T> and weak_atomic<T>.
My recollection is we explicitly did *not* want any additional member
functions in the strong atomics that weren't strong, among other reasons
because modern IDEs show all methods for an object in their intellisense...

We are not yet agreed whether it makes sense to allow the strong atomic ever
to be used in a weak way.
Does the use of 'weak' pollute the 'strong' users of the atomic or not?

I don't think we are all in agreement over this point yet.

If we decide there *are* cases where people want to call a mix of weak and
strong atomic functions on an atomic object, we
seem to have come up with three mechanisms so far.  [For example, Hans
suggested you'd prototype with strong atomics but could then
migrate *some* of the code to use weaker synchronisation]

A) Have the weak atomic publicly derive from strong atomic so you can create
a weak atomic object and pass it transparently to
code expecting a strong one.
B) Have a way to get from the strong atomic to a pointer to the C-style
opaque struct and use the free functions [either by public inheritance  (as
in N2145) or a member fn (my own preference)]
C) Provide overloads of the weak functions that take pointer to strong
atomic (this too is in N2145)

If we decide there are *no* cases when using a mix of calls is safe we can
just make strong and weak atomic classes unrelated.

We also have a possible question about how to do strong and weak atomics in
the C world.
Currently N2145 has a single atomic type for this (eg atomic_int) and a
number of named free functions and it is up to the user to make sure they
use the type safely.  Our feeling in Oxford was this was fine because C
programmers are used to a wide API and selecting the right subset of
functions.

However, if we decide that no conversion between strong and weak atomics is
safe in C++, do we want to make the same distinction in C?

Finally there are some open questions about how many extra features the C
style opaque struct might have when in namespace std when compiled using C++
rather than C.  For example, do we want operators in std::atomic_int ?
I think this is related to how much use we see C++ programmers would make of
weak_atomic<int> or atomic<int> versus atomic_int.

I also have a concern that, because of the combinatorial explosion of the
native types and the various accesses (ordered/relaxed/etc) we are in danger
of generating a very large number of structs/functions/classes/member
functions for something which we hope only a minority of C and C++
programmers will use...

For what its worth, I think we could consider dropping the weak_atomic<T>
class if we think those likely to use it would be equally happy to use the
free functions and the 'raw' atomic_int datatypes.

Regards,
Roger.