Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Fri Aug 26 2005 10:37 am

Alexander Terekhov wrote:
> Joe Seigh wrote: ...
> 
> <quote sources=tremblant.pdf>
> 
> 1.2 Ordering constraints
> 
> Perhaps the most contentious aspect of the design of the atomics 
> library has turned out to be the set of ordering constraints. This 
> matters for several reasons:
> 
> 1. Lock-free algorithms often require very limited and specific 
> constraints on the order in which memory operations become visible 
> to other threads. Even relatively limited constraints such as 
> “release”, may be too broad, and impose unneeded constraints on 
> both the compiler and hardware.
> 
> 2. Different processors often provide certain very limited 
> constraints at small or no additional cost, where the cost to 
> enforce something like an “acquire” constraint may be more major. 
> 
> [...]
> 
> 3. As discussed briefly below, adding further constraints appears 
> to significantly complicate the memory model.
> 
> At the moment, there is no clear consensus
> 
> </quote>
> 
> Why don't you simply spend your weekend studying the archives, Joe.
> 
> jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk
> 
I look at it occasionally but I don't spend a lot of time looking at
it if I see you're barking up the wrong tree.  You don't know how
to define semantics so you're looking at various implementations to
see if that gives you any ideas how to go about it, which it hasn't
so far.

I already *know* how to define semantics.  What's more, I work with
extremely esoteric (too esoteric according to some) synchronization
and nothing you guys appear to be doing would be of any use for me.

And you still haven stated what you mean by bidirectional and
unidirectional.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.