[cpp-threads] Re: Weak vs Strong Atomics

[Paul E. McKenney]

On Mon, May 07, 2007 at 12:36:57AM +0100, Roger Orr wrote:
> 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?

Not sure what you mean by "pollute" here...  If you choose not to use
the 'weak' variants, what do you mean by pollution?

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

Similarly, you might have code that used strong atomics that runs
too slowly, and thus need to move the fastpath to weaker and faster
primitives where doing so could be shown to be safe.  In my experience, it
is very frequently safe to do so.  See N2153 and its soon-to-be-released
successor for some examples.

> 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 could live with either of these approaches.  Either option A or B
might work best with the desired compatibility with C.  Not sure for 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.

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

That works for me.

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

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

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

Would this work for Java?

							Thanx, Paul