[cpp-threads] Re: Weak vs Strong Atomics

[Paul E. McKenney]

On Sun, May 06, 2007 at 08:43:13PM -0700, Lawrence Crowl wrote:
> 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)?

But this example uses both weak and variants.

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

What exactly do you mean by "perceive sequentially consistent operations"?

Are you asking that the weak operations by Module W be invisible to
Module S?  Are you asking that Module S's strong operations remain strong
in sequences of operations that do not contain accesses from Module W?
Are you expecting that Module W's operations somehow inherit SC-ness from
Module S's use of atomic variable A (although all non-SC sequences that I
am aware of involve at least two variables)?  Or something else entirely?

I would guess that there are multiple definitions of the word
"robustness" being assumed here.  ;-)

I would not expect to be guaranteed SC outcomes on a set of two or more
variables if any of them is subjected to both strong and weak operations.
If someone does expect this, I would be very interested in learning why
this is expected.

I would expect SC outcomes on any single atomic variable regardless of
the operations, again, because I believe that one needs at least two
variables to demonstrate a non-SC outcome.

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

I am hearing some rumblings of difficulties due to Java not permitting
basic types to be passed by reference.  I don't claim to understand this,
in particular, I don't understand why an atomic variable needs to be
a basic type in Java.  On the other hand, it has been many years since
I did much with Java.

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

There are in fact use cases where it makes sense to allow mixtures of
strong and weak operations.  These use cases are robust in the sense
that they can be shown to work correctly.

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

In section 5.2 of N2153, replace the rcu_assign_pointer() in the insert()
function with an ordered store.  This results in a safe algorithm.

More generally, take any working program that uses only weak operations.
Any of the publish-subscribe examples will do.  Strengthen one of the
operations (for example, turn a store_relaxed() into a store_ordered())
and the resulting mixed program also works.

Then take any working program that uses mixed operations (we now have
at least one).  Strengthen one of the weak operations, and the resulting
mixed program (or perhaps SC program) also works.

One might be tempted to present something like IRIW as a counterexample.
However, this fails, since although weak operations are not guaranteed
to be SC, they are also not guaranteed -not- to be SC.

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

Very good!

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

I will defer to Raul on the IBM compilers.  Anyone checked with the
gcc folks?

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

Let me try again:  Is is possible for Java to adopt a similar API with
similar weak-atomic semantics?

						Thanx, Paul