Multicores and Publication Safety

[Jb]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:g795mq$25jq$1 at digitalmars.com...
> Jb wrote:
>> What Bartoz said.. "writes to memory can be completed out of order and"
>>
>> Is not true on x86.
>
> It's risky to write such code, however, because:
>
> 1. someone else may try to port it to another processor, and then be 
> mystified as to why it breaks

You cant design / write your code based on the idea that someone who doesnt 
know what they are doing will try and modify it later. And if they are 
unaware of memory ordering they are likely unaware of alignment atomicity, 
and probably dont understand the subtleties of syncronization, and a whole 
bunch of other issues.

I'm not saying every joe blogs programmer should know about memory ordering 
and use it where they can to avoid more expensive syncronization primatives. 
But the compiler and stdlib, or multithreding librarys, should know about 
it. I dont think the compiler should be dumping memory fences all over the 
place on the assumtion that they might be needed by the x86 processors of 
2012.


> 2. Intel may change this behavior on future x86's, which means your code 
> will break years from now

I dont think they could because i think a lot of code probably already relys 
on it. And i think it's likely that the new comitment to strong memory 
ordering, from both AMD and INTEL (both have pdfs regarding 64 bit that 
specify it), is mainly because they realize it is needed to help progress 
with multi core.