Subj : Re: Using hierarchical memory as an acquire memory barrier for  dependentloads
To   : comp.programming.threads,comp.arch
From : Joe Seigh
Date : Mon Sep 12 2005 12:42 pm

Alexander Terekhov wrote:
> Joe Seigh wrote:
> [...]
> 
>>You don't need it on most systems since they have dependent load ordering.
> 
> 
> Compilers can turn dd into cc and reorder, "incorrect" software value 
> prediction aside for a moment. AFAICS, 20020194436 is about hacking

The OP is addressing hardware not compiler issues.
> 
> http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html

Which is why I used the word "most".  Dependent load ordering isn't part
of any of the official memory models as far as I know so the behavior
was allowable.  It's also allowable on x86 so it's conceivable that
future Intel or AMD processors could require memory barriers to guarantee
dependent load ordering.  Since that hasn't happened yet, it's impossible
to tell how expensive the memory barrier would be.  Since multi-threaded
synchronization mechanisms have certain assumptions of efficiency, it's
always good to have alternative implementations as part of your back up
plans.  It's a robustness of design issue.

> It won't help against "incorrect" hardware value prediction, I'm afraid.

Not at the cache level but you could do it that the virtual memory level
by mapping the new data into the reader memory address range as part of
the release operation.  It's probably more expensive than you want it to
be but it has to work because that's what the virtual memory manager does
when it pages in from backing store.

-- 
Joe Seigh

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

.