Something needs to happen with shared, and soon.

[Andrei Alexandrescu]

On 11/14/12 7:11 AM, Alex Rønne Petersen wrote:
> 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.

The language definition should be made clear so as future optimizations 
of existing implementations, and future implementations, don't push 
things over the limit.

Andrei