Something needs to happen with shared, and soon.

[deadalnix]

Le 15/11/2012 17:33, Sean Kelly a écrit :
> On Nov 15, 2012, at 4:54 AM, deadalnix<deadalnix at gmail.com>  wrote:
>
>> Le 14/11/2012 21:01, Sean Kelly a écrit :
>>> On Nov 14, 2012, at 6:32 AM, Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>   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.