Something needs to happen with shared, and soon.

[Andrei Alexandrescu]

On 11/14/12 8:59 AM, David Nadlinger wrote:
> 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.

First, there are more kinds of atomic loads and stores. Then, the fact 
that the calls are not supposed to be reordered must be a guarantee of 
the language, not a speculation about an implementation. We can't argue 
that a feature works just because it so happens an implementation works 
a specific way.

> 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.

Nowhere in the language definition is explained what an opaque function 
call is and what optimizations can and cannot be done in the presence of 
such.

> So, either we are
> fine by definition,

s/definition/happenstance/

> 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.

Using load/store everywhere would make volatile unneeded (and for us, 
shared). But the advantage there is that you qualify the type/value once 
and then you don't need to remember to only use specific primitives to 
manipulate it.


Andrei