Something needs to happen with shared, and soon.

[Sean Kelly]

On Nov 14, 2012, at 12:07 PM, Alex Rønne Petersen <alex at lycus.org> wrote:

> On 14-11-2012 21:00, Sean Kelly wrote:
>> On Nov 14, 2012, at 6:16 AM, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
>> 
>>> On 11/14/12 1:20 AM, Walter Bright wrote:
>>>> On 11/13/2012 11:37 PM, Jacob Carlborg wrote:
>>>>> If the compiler should/does not add memory barriers, then is there a
>>>>> reason for
>>>>> having it built into the language? Can a library solution be enough?
>>>> 
>>>> Memory barriers can certainly be added using library functions.
>>> 
>>> The compiler must understand the semantics of barriers such as e.g. it doesn't hoist code above an acquire barrier or below a release barrier.
>> 
>> That was the point of the now deprecated "volatile" statement.  I still don't entirely understand why it was deprecated.
>> 
> 
> The volatile statement was too general. All relevant compiler back ends today only know of two kinds of volatile operations: Loads and stores. Volatile statements couldn't ever be properly implemented in GDC and LDC for example.

Well, the semantics of volatile are that there's an acquire barrier before the statement block and a release barrier after the statement block.  Or for a first cut just insert a full barrier at the beginning and end of the block.  Either way, it should be pretty simply for a compiler to handle if the compiler supports mutex use.

I do like the idea of built-in load and store intrinsics only because D only supports x86 assembler right now.  But really, it would be just as easy to fan out a D template function to a bunch of C functions implemented in separate ASM code files.  Druntime actually had this for core.atomic on PPC until not too long ago.