Something needs to happen with shared, and soon.

[David Nadlinger]

On Wednesday, 14 November 2012 at 14:32:34 UTC, 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).

Sorry, I don't quite see where I simplified things. Yes, in the 
implementation of atomicLoad/atomicStore, one would probably use 
compiler intrinsics, as done in LDC's druntime, or inline 
assembly, as done for DMD.

But an optimizer will never move instructions across opaque 
function calls, because they could have arbitrary side effects. 
So, either we are fine by definition, or if the compiler inlines 
the atomicLoad/atomicStore calls (which is actually possible in 
LDC), then its optimizer will detect the presence of inline 
assembly resp. the load/store intrinsics, and take care of not 
reordering the instructions in an invalid way.

I don't see how this makes my answer to deadalnix (that 
»volatile« is not necessary to implement sequentially 
consistent loads/stores) any less valid.

David