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