Multicores and Publication Safety

[Sean Kelly]

Jb wrote:
> "Sean Kelly" <sean at invisibleduck.org> wrote in message 
> news:g78man$17sb$1 at digitalmars.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.
>> Not true.  The actual behavior of IA-32 processors has been hotly debated, 
>> but it's been established that at least certain AMD processors may reorder 
>> loads.
> 
> Thats news to me.
> 
> 
>> Also, even under the PCsc model it is completely legal to "hoist" loads 
>> above stores, or equivalently, to "sink" stores below loads.
> 
> Yes but as long as stores are not reordered with other stores, and loads not 
> reordered with other loads, then that kind of re-ordering wont result in the 
> situation Bartoz described.

True enough.  It's mostly an issue with creating mutexes and the like.


Sean