[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

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.
>
> 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
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>


-- 
Lawrence Crowl