[cpp-threads] memory model

[Alexander Terekhov]

On 4/29/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> If I understand correctly, Alexander is proposing a template
> 
> atomic<T> which is a class containing a T along with a bunch
> of atomic operations to access the value.  Each atomic operation
> is templatized wrt a particular ordering constraint.

In addition to that (and proper isolation), atomic<T> is also 
meant to provide naked atomics, and noncompeting and 
exclusive accesses.

> 
> I think this makes sense.  But it leaves some questions open:
> 
> 1) What do we do if the hardware cannot provide the requested
> operation?  

Such as?

> Do we emulate it with locks?  

Makes no sense to me. I can do better with locks.

> Do we disable "signals"?

?? Assume MP.

> (I think the latter is beyond the scope of the standard, but I think
> informal guidance is essential for this to be useful.)
> Presumably we provide tests as to whether it is implemented at all/
> implemented efficiently?

Yup. And certification program with logo. ;-)

> 
> 2) What ordering constraint do we need?
> 
> Alexander has one set in
> http://www.google.de/groups?selm=41276DBB.2023556D%40web.de
> I have another set in
> http://www.hpl.hp.com/research/linux/atomic_ops/README.txt,
> about 2/3 of the way down.
> 
> They're fairly similar, but not identical.
> 
> I have some technical questions here:
> Are there any architectures on which a load and a data-dependent store
> are not ordered?

On Alpha, I suppose.

> 
> On what architectures do control dependences imply ordering?  

cchsb is implied universally, I think.

> I have
> a vague recollection that on PowerPC there is something along these
> lines?  

Safe Fetch ("branch never taken" trick) to impose load->store
ordering is documented in Book II. 

> I would otherwise find it surprising, since correctly
> predicted branches don't normally have much impact on the operation
> of modern processors.

Msync on Power is so 20th century... ;-)

> 
> I'm actually not sure what to do about the ordering constraints
> in both proposals that mention data-dependence or control-dependence.
> Thinking about this a bit more, I'm not sure those really make
> sense at this level for the same reasons we avoided mentioning
> them in the Java spec.  The compiler can easily convert between
> them, or optimize/pessimize away the dependency.

I doubt it.

regards,
alexander.