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