[cpp-threads] modes

[Doug Lea]

Peter Dimov wrote:
> Doug Lea wrote:
> 

> 
> Let's talk about reference counting. :-)
> 
> Required primitives for mutable objects:
> 
> A. atomic increment, unconstrained
> B. atomic decrement, release on nonzero, code-conditional acquire on zero
> C. atomic increment on nonzero, unconstrained (for weak pointer support)
> 
> (slightly relaxed decrement aside for a moment)
> 
> Immutable objects:
> 
> D. atomic decrement, sink-load on nonzero, code-conditional hoist-store on 
> zero
> 
> (A) and (C) would be expressible by your basic set if you add unconstrained 
> CAS, although the best implementation of (A) on x86 or IA64 isn't CAS, but 
> fetch_and_add.
> 

Aside: I haven't checked this in about 3 years, but at the time,
incrementing using CAS (with retry) on x86-smps I had around was not
reliably slower than locked add.

But in any case, we'd like to spec that atomic_int.get_and_increment (or
whatever) has the semantics it would have as if it were done this way.
Which might even lead to multiple versions of this operation to reflect
the underlying flavors of the CAS. Although just settling for one
and letting people get the others via explicit CAS loops would probably
be fine.

One question is whether distinguishing CAS.none buys you anything vs
CAS.rel wrt performance on current or plausible future platforms. Which
I think is mainly another empirical question about PPC-smps. (I don't
have one around to check either.)


> (B) is expressible with CAS.acq and CAS.rel, but the best implementation on 
> x86 is fetch_and_add, and on PPC under contention it would incur more 
> synchronization than necessary (this may or may not be measurable in 
> practice; I don't have a dual PPC to test).

> 
> (D) is expressible with CAS.rel and CAS.none, provided that our memory model 
> gives us the guarantee that stores are never hoisted across a control 
> dependency (true on all existing hardware absent compiler reordering). The 
> above caveats still apply.

Right.

-Doug