[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

On 5/4/07, Raul Silvera <rauls at ca.ibm.com> wrote:
> Lawrence Crowl wrote on 05/03/2007 12:50:20 AM:
> > At the Oxford meeting there was a decision to have weak versus
> > strong atomics so that strong atomics couldn't be reused weakly,
> > thus failing to provide sequential consistency.  I think that the
> > decision should be reconsidered, or at least modified.
> >
> > First, I don't think the notion that you can pass a weak atomic
> > to a module expecting a strong atomic actually works.  The passee
> > may be expecting SC semantics, but the passer may still be using it
> > weakly, thus failing SC.  Conversely, as noted, passing a strong
> > atomic to a weak atomic also may yield non-SC behavior to the
> > passer.  So, at a minimum, meeting the stated goal of the decision
> > requires complete isolation of the weak atomics from the strong
> > atomics, and that was not my understanding of the decision.
> >
> > Second, I don't think atomic variables are likely to be shared among
> > disparate code.  The reason is that the use of atomic variables is an
> > implementation technique, not an interface issue.  For example, a
> > queue could be implemented with either mutexes or with atomics,
> > and that decision is an implementation decision.  There might be
> > lock-free semantics exported, but the specific atomic variables are
> > typically not exported and not part of the interface.  So the notion of
> > passing these variables to an uncooperative software module seems
> > implausible.
> >
> > Based on these two observations, I would like to keep the current
> > design for atomics, which is a single atomic type and a functional
> > interface to all operations and an operator interface to the strong
> > operations.
> >
> > Comments?
> >
>
> Hi, Lawrence... First let me introduce the motivation as to why
> we want replaceability of strong atomics with weak atomics. We foresee
> situations where a program is initially written using strong atomics,
> but later as part of a tuning effort weak atomic operations are introduced
> selectively on the performance-sensitive sections of the program.

We agree on the goal.  If you interpreted my message as not supporting
this goal, I apologize for not being clear.

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

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

When a weak view destroys a strong view, any inheritance relationship
between weak and strong types will still cause the strong view to fail.
That is, the only way to protect a strong view is to have completely
separate types.

When a strong view is robust to a weak view, as you and Hans suggest,
there is no need to protect an atomic variable against a weak view, the
only thing a module must do to protect its strong view is to use only fully
ordered operations.  Indeed, a separate type may be counter-productive
because it would prevent optimization of a module that shares a variable
of strong type with another module.

Before I go into more analysis of our choices, I would like some feedback
on the above analysis.  Are we dealing with "weak destroys strong" or
with "strong is robust to weak"?  Do you agree that an inheritance
relationship serves neither case well?

-- 
Lawrence Crowl