Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Neill Clift [MSFT]
Date : Mon Feb 07 2005 08:52 am

"Alexander Terekhov" <terekhov@web.de> wrote in message 
news:42074D46.D6062F0D@web.de...
>
> "Neill Clift [MSFT]" wrote:
> [...]
>> I have seen you complain about the spinlock unlock
>> routine that uses a volatile store.
>
> If your volatiles have Java-post-JSR-133-like "release+" semantics
> for writes (note: totally unneeded for standard C/C++ semantics -- 
> sig_atomic_t statics for async signals and auto locals for jumps),
> then you don't need that idiotic "WithoutFence". If your volatiles
> don't have Java-post-JSR-133-like "release+" semantics for writes,
> then that "WithoutFence" thing won't help (on Itanic MP).

I think your missing the point that our compiler is changing.
It's neither of these two states currently.
In shipped compilers we only honour ordering volatile to volatile
statements. On IA64 we are generating acquire and release
semantics for volatile references. It may well be that in the
future we shift to an acquire/release model for volatile references.
We could have already done so as I don't work on the compiler.

>
> [... InterlockedCompareExchange ...]
>
>> You also suggested we don't do the right thing on
>> the alpha.
>
> I suggested you post the code. Still waiting.

Yeah like thats going to happen.

>
>> I believe we do have a full barrier
>
> I believe that barrier makes little sense in the case of
> comparison failure.
>

Well the problem with that is that in the failure case the CAS
still returns a usable value. I could easily constuct a reasonable
program taking advantage of this. Callers would likely expect
ordering here. It's likely many existing program take advantage
of this. Even if you define it as undefined unless people actualy
see something go wrong they likely code to the implementation.
For us the penetration of x86 forces it's rules in many areas.
Neill.

.