[cpp-threads] Weak vs Strong Atomics

[Raul Silvera]

Larwence Crowl wrote on 05/04/2007 02:14:49 PM:

> > An inheritance relationship will allow the programmer to replace the
> > declaration of a strong atomic variable with a weak atomic with minimal
> > source changes and without changing the program semantics (weak atomics
> > behave as strong atomics by default) and then selectively replace
> > individual atomic operations with weakly ordered operations.
>
> A single type also meets that goal.

Agreed. I'm glad to see we're on the same page on the fundamental issues.

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

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.

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.

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

--
Raúl E. Silvera         IBM Toronto Lab   Team Lead, Toronto Portable
Optimizer (TPO)
Tel: 905-413-4188 T/L: 969-4188           Fax: 905-413-4854
D2/KC9/8200/MKM