Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Neill Clift [MSFT]
Date : Sat Feb 05 2005 03:15 pm

"Alexander Terekhov" <terekhov@web.de> wrote in message 
news:4204C753.D084D04F@web.de...
>
> I doubt it. KeMemoryBarrier* idiocy and braindead illustrations from
> that piece speak volumes to the contrary.
>
I have seen some discussion from you on this point but it's
basically quite hard to deduce your point from many of your
posts. I have had to ask you for clarification on things before
but I haven't expended that energy for all of them.
To be honest I think the name
KeMemoryBarrierWithoutFence was a poor choice for a
statement name. I would have picked a name that made it
more obvious that we were preventing compiler reordering
around this point.
I have seen you complain about the spinlock unlock
routine that uses a volatile store. I call this the unlock
optimization when I talk about it. With release semantics
in the compiler (or a statement to prevent compiler
reordering) and release semantics for the processor
via special instructions we believe this is a valid
optimization. Clearly there are some sequences that
may not work with the unlock optimization that
would work with a full barrier:

lock ();
a = 1;
unlock ();

if (b) {
    xxx;
}

The read of b might be rearranged to before the
assignment of a. Algorithms like Petersons that rely
on a write followed by a read can't be made to work
by inserting an unlock before the reads. I don't believe
this is problem in practice. Anyone doing this has
references to memory locations that can change
outside of locks and hence has to know about
barriers.

You have also complained about the fact that
we don't document that
InterlockedCompareExchange is not a barrier
in the failure case. I have confirmed that I
believe it's our intention. You have complained
that you don't believe it's the case for some future
supported XBOX platform I have no knowledge of.
You also suggested we don't do the right thing on
the alpha. I believe we do have a full barrier
for this call such that you can't get rearrangements
like this between the assignment of a and b:

a = 1;
if (InterlockedCompareExchange (&z, 1, 0) != 0) { // fails
    b = 2;
}

I believe there is a problem with something like this:

if ((a = InterlockedCompareExchangePointer (&z, p1, p2)) != p2) { // fails
    a->val = 1;
}

Here the assignment to a->val may be reordered to before
the interlocked operation (well before the load locked etc
but not before the mb). All ancient history as we don't
develop for this platform now.

So if you explain your issues in a way I can understand.
Clearly stating what you think is an issue I could send
details to the appropriate people and try and effect
change if I agree.
Neill.

.