[cpp-threads] Re: Weak vs Strong Atomics

[Lawrence Crowl]

On 5/6/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> On Mon, May 07, 2007 at 12:36:57AM +0100, Roger Orr wrote:
> > 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?
>
> Not sure what you mean by "pollute" here...  If you choose not to use
> the 'weak' variants, what do you mean by pollution?

Module S uses only strongly ordered operations on atomic variable A.
Module W uses (at least some) weakly ordered operations on A.
Will S perceive sequentially consistent operations (robust)
or will S perceive sequentially inconsistent operations (polluted)?

At present, I think I've only heard claims of robustness.

> > 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)

I don't think of N2145 as behaving this way.  I think of N2145 more as
a single atomic type, but the weak operations are only available as free
functions.  Can anyone not live with this?

> I could live with either of these approaches.  Either option A or B
> might work best with the desired compatibility with C.

Actually, I think N2145 does pretty well here.

>  Not sure for Java.

I don't understand where Java came from.  To the best of my knowledge,
any Java compatibility is in the conceptual memory model, not in the
detailed syntax and semantics.  Am I wrong?

> > 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.
>
> Again, see N2153.

And the answer is....

> > 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?
>
> Why would it be unsafe?  Please give an example.

In the absence of an example that it is unsafe, or a proof that it is safe,
we are skating on the unknown.

> > 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.
>
> My vote would be to have C interfaces corresponding to the C++ operators.

Those exist in N2145.  The issue, I think is whether "atomic_int x; x+=3;"
works.  That is, can you apply C++ operators to a variable declared in a
C header.  In N2145, it can.

> > 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...

Peter Dimov, Hans Boehm, and I have basically agreed that the ordering
should be made into a parameter, rather than part of the function name.
On the down side, t increases the implementation effort required to
achieve the same efficiency, but not beyond what major optimizers are
already doing.  On the up side, it makes specification simpler and will
increase the ease of some generic algorithms.

> > 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.

That is my big question.  Raul said earlier that he is not entirely
happy with it, but has not yet said whether or not he can live with it.

> Would this work for Java?

I don't understand this question.

-- 
Lawrence Crowl