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