[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

On 5/6/07, Raul Silvera <rauls at ca.ibm.com> wrote:
> Lawrence Crowl wrote on 05/04/2007 02:14:49 PM:
>
> My main objection to your current proposal is that the C++ access to weak
> atomics has a cumbersome syntax; is not much better than dropping down to
> the C compatible layer. It begs the question as to why provide weak C++
> atomics at all.

Well, as you point out, performance.  Do you really think writing
atomic_fetch_add_relaxed(x,3) versus x.fetch_add_relaxed(3) will make
a significant difference to programmers at this level?

> From my point of view strong atomics are just a prototyping
> tool; we will strongly encourage programmers to use weak atomics, so we
> would like to avoid complicated syntax that would conceal their existence
> and discourage their use.

And your view is quite different from Herb's.

Can you explain what you mean by "conceal their existence"?  Anything
in the standard is by definition not concealed, so you must have something
more specific in mind.

> While I would prefer to have a single type, that type would have to be the
> weak one, not the strong one. A single atomic type that provides SC on the
> default operations and named member functions for more-weakly ordered
> operations, would probably satisfy at least Nick's concerns.

That would require a type-based static analysis tool.  The free functions
work better with grep.

> The new proposal using a derived type allows reasonable C++ access to weak
> atomics while still satisfying Herb's requirements, so I think it is a
> reasonable compromise.

Are you willing to live with being unable to get back to a weak atomic
once an interface makes it strong?

> > > With respect to your first argument, I don't think that it is in
> reality
> > > a problem. There will still be SC on the operations performed by the
> > > passee, and the passee cannot be expecting SC on operations performed
> > > by the passer, since it does not have any visibility into that code.
> >
> > And herein lies my concern, which in the interests of trying to avoid
> > miscommunication, I will be excessively verbose.  Consider a "strong
> > view" of a set of atomic variables.  The operations on those variables
> > are all fully ordered and the behavior of those operations is
> sequentially
> > consistent. Conversely, there is a "weak view" in which some operations
> > are not fully ordered and the behavior is not sequentially consistent.
> >
> > Now consider a module with a strong view and a module with a weak
> > view that uses (some of) the same atomic variables.  Now either the
> > weak view will destroy the strong view (render the operations not
> > sequentially consistent) or the strong view is robust to the weak view.
>
> I disagree with the assertion that the weak-view module will interfere or
> somehow destroy the strong view of the other module.

Apparently I wasn't verbose enough.  I made no such assertion.  I only
said it had to be that _or_ something else.

> The weak module cannot
> interfere with the SC of the operations from the strong module; those will
> still follow program order. The operations of the weak module may or may
> not follow program order, but the program order of the weak module is
> unknown to the strong module anyway.

Just what I wanted to hear.  Does anyone disagree with this statement?

> If there is some program convention
> indicating how to access these shared variables, that convention must state
> whether those accesses must be strong or weakly ordered.
>
> Perhaps part of the issue is that there seems to be an assumption that only
> SC operations can be applied to strong atomics. That is not true; weakly
> ordered operations are still available, either through inheritance (in the
> case of references or pointers to weak atomics) or by dropping down to the
> C-compatible layer. This is also true for your previous proposal, so I find
> that this isn't a differentiator between the two approaches.

My understanding of what Herb would like, in the strong form, is that
only SC operations can be applied to SC types, as a means to enforce
programming guidelines.

-- 
Lawrence Crowl