[cpp-threads] Weak vs Strong Atomics

[Anthony Williams]

"Lawrence Crowl" <Lawrence at Crowl.org> writes:

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

That is my recollection.

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

It is possible that the decision was made after I left, or my recollection is
wrong, but I thought we decided to have atomic<T> be the SC "strong" atomic,
and weak_atomic<T> be the weak one, with no conversions between them, for
precisely the reasons you state. The weak_atomic<T> would have the same
operators as atomic<T>, and they would behave just as for the atomic<T>, but
there would be additional member functions that provided weaker
semantics. This would allow optimization of a specific section of code just by
changing the declaration of the atomic, and using the weaker operations where
desired, without requiring a change to code elsewhere. I don't remember there
being consensus on how this mapped to C-compatible types, and whether there
should be one or two C types.

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

I agree that you're unlikely to pass atomic variables around without some idea
of what they're going to be used for.

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

Doing so does not allow for the possibility of a strong atomic where all
operations are guaranteed SC. I am not happy with this.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL