Something needs to happen with shared, and soon.

Sean Kelly sean at invisibleduck.org
Wed Nov 14 16:48:18 PST 2012


On Nov 14, 2012, at 2:21 PM, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

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

Fair enough.  Though this may mean building a bunch of different forms of volatility into the language.  I always saw "volatile" as a library tool anyway, so while making it code-related was a bit weird, it was a sufficient tool for the job.



More information about the Digitalmars-d mailing list