Something needs to happen with shared, and soon.

[Sean Kelly]

On Nov 15, 2012, at 5:10 AM, deadalnix <deadalnix at gmail.com> wrote:

> Le 14/11/2012 23:21, Andrei Alexandrescu a écrit :
>> On 11/14/12 12:00 PM, 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.
>> 
>> Because it's better to associate volatility with data than with code.
> 
> Happy to see I'm not alone on that one.
> 
> Plus, volatile and sequential consistency are 2 different beast. Volatile means no register promotion and no load/store reordering. It is required, but not sufficient for concurrency.

It's sufficient for concurrency when coupled with library code that does the hardware-level synchronization.  In short, a program has two separate machines doing similar optimizations on it: the compiler and the CPU.  In D we can use ASM to control CPU optimizations, and in D1 we had "volatile" to control compiler optimizations.  "volatile" was the minimum required for handling the compiler portion and was easy to get wrong, but it used only one keyword and I suspect was relatively easy to implement on the compiler side as well.