Something needs to happen with shared, and soon.

deadalnix deadalnix at gmail.com
Thu Nov 15 05:10:14 PST 2012


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.


More information about the Digitalmars-d mailing list