Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

On 14-11-2012 15:32, Andrei Alexandrescu wrote:
> On 11/14/12 4:23 AM, David Nadlinger wrote:
>> On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
>>> That is what java's volatile do. It have several uses cases, including
>>> valid double check locking (It has to be noted that this idiom is used
>>> incorrectly in druntime ATM, which proves both its usefullness and
>>> that it require language support) and disruptor which I wanted to
>>> implement for message passing in D but couldn't because of lack of
>>> support at the time.
>>
>> What stops you from using core.atomic.{atomicLoad, atomicStore}? I don't
>> know whether there might be a weird spec loophole which could
>> theoretically lead to them being undefined behavior, but I'm sure that
>> they are guaranteed to produce the right code on all relevant compilers.
>> You can even specify the memory order semantics if you know what you are
>> doing (although this used to trigger a template resolution bug in the
>> frontend, no idea if it works now).
>>
>> David
>
> 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).
>
> Andrei

They already work as they should:

* DMD: They use inline asm, so they're guaranteed to not be reordered. 
Calls aren't reordered with DMD either, so even if the former wasn't the 
case, it'd still work.
* GDC: They map directly to the GCC __sync_* builtins, which have the 
semantics you describe (with full sequential consistency).
* LDC: They map to LLVM's load/store instructions with the atomic flag 
set and with the given atomic consistency, which have the semantics you 
describe.

I don't think there's anything that actually needs to be fixed there.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org