[cpp-threads] Weak vs Strong Atomics

[Paul E. McKenney]

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.

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.

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

						Thanx, Paul