Multicores and Publication Safety

Jb jb at nowhere.com
Tue Aug 5 01:22:54 PDT 2008


"Brad Roberts" <braddr at puremagic.com> wrote in message 
news:mailman.10.1217908384.1156.digitalmars-d at puremagic.com...
> Jb wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message
>> news:g7855a$2sd3$1 at digitalmars.com...
>>> "What memory fences are useful for on multiprocessors; and why you 
>>> should
>>> care, even if you're not an assembly programmer."
>>>
>>> http://bartoszmilewski.wordpress.com/2008/08/04/multicores-and-publication-safety/
>>>
>>> http://www.reddit.com/comments/6uuqc/multicores_and_publication_safety/
>>
>> None of that is relevant on x86 as far as I understand. I could only find
>> the one regarding x86-64, but as far as I know it's the same on x86-32.
>>
>> http://www.intel.com/products/processor/manuals/318147.pdf
>>
>> The key point being loads are not reordered with other loads, and stores 
>> are
>> not reordered with other stores.
>>
>
> Pay very close attention to sections 2.3 and 2.4 of that document.

They dont override 2.1, they complement it. IE...

*Stores cannot be reordered with other stores*
*Loads cannot be reordered with other loads*

x = 1;
ready = 1;

Happens in order whether or not a load is reordered with those stores. You 
cant have a situation where a processor sees the write to "ready" before it 
sees the write "x".

What Bartoz said.. "writes to memory can be completed out of order and"

Is not true on x86.

What 2.3 is saying is that a later load could be reordered before either 
store, but it still cant be reordered before the store to 'x' and after the 
store to 'ready', because the order of those stores cannot be changed. If it 
gets reordered before the store to 'x' it implicity gets reordered before 
the store to ready.

That's the whole point of the ordering of stores / loads being enforced.

Reagrding 2.4 : What this is saying is that there may be a delay between 
processors seeing each others stores, not that they can be seen out of 
order. Processor 1 may see it's own write to 'x' before processor 2 does, 
but processor 2 still wont see the write to 'ready' before the write to 'x'.









More information about the Digitalmars-d mailing list