Multicores and Publication Safety

[Walter Bright]

Jb Wrote:

> 
> "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.

The model the compiler uses is to generate code "as if" fences were inserted everywhere. The compiler may, however, as part of optimization and generating code for a particular CPU, elide as many as it can.


> > 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.

I think that is because the current language technology is deficient. We aim to fix that with D :-)