[cpp-threads] Weak vs Strong Atomics

[Paul E. McKenney]

On Wed, Jun 06, 2007 at 03:22:55PM -0700, Lawrence Crowl wrote:
> Final call for comments before I write up the next version...
> 
> On 6/1/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> >On Thu, May 31, 2007 at 03:19:14PM -0700, Lawrence Crowl wrote:
> >> Getting back to this topic, ....
> >>
> >> The earlier consensus was that if you used only sequentially
> >> consistent operations on an atomic variable, you would view
> >> sequentially consistent behavior even if other operations on that
> >> object were weaker.  So, the core requirement for style checking
> >> is that one be able to identify weak operations, not that one be
> >> able to identify weak types.  Therefore, a weak type is probably
> >> not the right solution.
> >>
> >> Let me propose an alternate solution, which takes advantage of
> >> parameterizing the ordering.  In outline, we have an enum that
> >> indicates the ordering properties.
> >>
> >> typedef enum memory_ordering {
> >>        memory_ordering_relaxed, memory_ordering_acquire,
> >>        memory_ordering_release, memory_ordering_acq_rel,
> >>        memory_ordering_seq_cst
> >> } memory_ordering;
> >>
> >> Weak operations must then have an explicit parameter of this type,
> >> and one can thereby identify the weak operations by grepping for
> >> "memory_ordering".
> >>
> >> For example, fetch-and-add operations on atomic_int would look like:
> >>
> >> // C view
> >> i = atomic_fetch_add( & ai, 3 );
> >> i = atomic_fetch_add_expert( & ai, 3, memory_ordering_release );
> >> // C++ view
> >> i = ai.fetch_add( 3 );
> >> i = ai.fetch_add( 3, memory_ordering_release );
> >> i = ai += 3;
> >>
> >> Will this approach meet the needs?
> >>
> >> N2145 does not have a fetch_add member function.  If you want it,
> >> why is the non-member function not sufficient.  If you do not want
> >> it, why is it a problem?
> >>
> >> I'm not excited about _expert, and welcome alternatives.  One
> >> representative of the C committee recommended against type-generic
> >> macros with variable number of arguments on the basis of insufficient
> >> prior art.  In addition, prototyping such macros is difficult.
> >> Hence, the second function rather than a default argument.
> >
> >Future concurrent C/C++ programmers will more definitely not be thanking
> >us for hard-coding the limits of today's parallel programming pedagogy
> >into the C/C++ standard.

I stand by this.

> >How about using the newly proposed attribute facility to mark member
> >functions as having specified attributes from an IDE viewpoint?  Then
> >we can just have member function for everything, and the non-SC
> >member functions can be so marked: "[[IDE(non_SC)]]" or some such.
> >IDEs could be configured not to suggest "non_SC" member functions,
> >but people who need to use them can configure their IDEs to suggest
> >them if desired.
> >
> >Perhaps even better would be to have profiles in the IDEs themselves that
> >limit what the IDE will show, thus allowing advances in the understanding
> >of how to teach concurrency to be accommodated without having to change
> >the C/C++ standards.  In addition, such an approach would accommodate
> >different needs of different groups of programmers.

And by this.

> >Using the enum to encode the memory-model effects actually looks good to
> >me, though I would argue for "_ordered" or "_sc" rather than "_seq_cst".

But withdraw this last.  "memory_ordering_ordered" does not exactly
roll off the tongue, and "memory_ordering_sc" seems a bit terse (though
nice from a typing perspective).  I still am not happy with _seq_cst,
but am not so sure that my earlier suggestions are an improvement.

							Thanx, Paul