[cpp-threads] Weak vs Strong Atomics

Lawrence Crowl Lawrence at Crowl.org
Thu May 3 05:50:20 BST 2007


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?

-- 
Lawrence Crowl



More information about the cpp-threads mailing list