On Nov 14, 2012, at 2:21 PM, Andrei Alexandrescu <[email protected]> wrote:
> On 11/14/12 12:00 PM, Sean Kelly wrote: >> On Nov 14, 2012, at 6:16 AM, Andrei >> Alexandrescu<[email protected]> 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.
