[cpp-threads] modes

Peter Dimov pdimov at mmltd.net
Sat May 7 20:29:34 BST 2005


Doug Lea wrote:
> Alexander (and Peter?), how about you humor me and, for each mode you
> like not in minimal list, present a case that arguably meets the
> criteria ...
>
>> only if there are compelling use cases for modes needed in
>> constructions that:
>>     1. arise in common or important situations,
>>     2. can't be expressed without special modes,
>>     3. will remain inefficient even when compilers start
>>        routinely optimizing wrt memory barriers etc in compliant
>> code, 4. will remain useful even as hardware vendors continue
>>        with their (very) recent trends to make most barriers etc
>>        cheaper (and thus less worthwhile to evade in corner cases).

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.

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

So... I need to know whether CAS.acq and CAS.none are in your minimal list, 
so that I can run A-D against 1-4. (I also need to know whether our 
"expanded" memory model guarantees that stores aren't hoisted across a 
control dependency, Alexander's hypothetical rollback memory architecture 
aside.) 





More information about the cpp-threads mailing list