On Nov 14, 2012, at 12:07 PM, Alex Rønne Petersen <[email protected]> wrote:
> On 14-11-2012 21:00, 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. >> > > The volatile statement was too general. All relevant compiler back ends today > only know of two kinds of volatile operations: Loads and stores. Volatile > statements couldn't ever be properly implemented in GDC and LDC for example. Well, the semantics of volatile are that there's an acquire barrier before the statement block and a release barrier after the statement block. Or for a first cut just insert a full barrier at the beginning and end of the block. Either way, it should be pretty simply for a compiler to handle if the compiler supports mutex use. I do like the idea of built-in load and store intrinsics only because D only supports x86 assembler right now. But really, it would be just as easy to fan out a D template function to a bunch of C functions implemented in separate ASM code files. Druntime actually had this for core.atomic on PPC until not too long ago.
