Le 15/11/2012 17:33, Sean Kelly a écrit :
On Nov 15, 2012, at 4:54 AM, deadalnix<[email protected]> wrote:
Le 14/11/2012 21:01, Sean Kelly a écrit :
On Nov 14, 2012, at 6:32 AM, Andrei Alexandrescu<[email protected]>
wrote:
This is a simplification of what should be going on. The
core.atomic.{atomicLoad, atomicStore} functions must be intrinsics so the
compiler generate sequentially consistent code with them (i.e. not perform
certain reorderings). Then there are loads and stores with weaker consistency
semantics (acquire, release, acquire/release, and consume).
No. These functions all contain volatile ask blocks. If the compiler respected the
"volatile" it would be enough.
It is sufficient for monocore and mostly correct for x86. But isn't enough.
volatile isn't for concurency, but memory mapping.
Traditionally, the term "volatile" is for memory mapping. The description of
"volatile" for D1, though, would have worked for concurrency. Or is there some example
you can provide where this isn't true?
I'm not aware of D1 compiler inserting memory barrier, so any memory
operation reordering done by the CPU would have screwed up.
