[cpp-threads] memory model

[Boehm, Hans]

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.

I think this makes sense.  But it leaves some questions open:

1) What do we do if the hardware cannot provide the requested
operation?  Do we emulate it with locks?  Do we disable "signals"?
(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?

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 what architectures do control dependences imply ordering?  I have
a vague recollection that on PowerPC there is something along these
lines?  I would otherwise find it surprising, since correctly
predicted branches don't normally have much impact on the operation
of modern processors.

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 think we should definitely allow any combination of acquire and
release (i.e. all 4 possibilities).  I'm unsure about anything else.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Alexander Terekhov
> Sent: Thursday, April 28, 2005 7:32 AM
> To: Doug Lea
> Cc: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] memory model
> 
> 
> On 4/28/05, Doug Lea <dl at cs.oswego.edu> wrote:
> [...]
> > That said, Alexander: I think most people are in favor of something 
> > close to your atomic templates. Could you write up and send 
> to list a 
> > self-contained initial proposal for people to work on?
> 
> I do not know much about writing proposals: that is not my 
> trade. 
> 
> Hoist and sink stuff is nothing but constituents of classic 
> acquire and release. As for cc and dd on hoist stuff, they 
> are simply optimizations meant to take advantage of implied 
> ordering due to data dependencies and conditional branching 
> on existing hardware (e.g. cchsb is implied on all existing 
> hardware and ddhsb/ddhlb/ddacq on everything except {RIP-} 
> Alpha AFAIK). See also:
> 
> http://www.google.de/groups?selm=4251896E.5D7F03D5%40web.de
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk