Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

On 14-11-2012 21:15, Sean Kelly wrote:
> On Nov 14, 2012, at 12:07 PM, Alex Rønne Petersen <alex at lycus.org> wrote:
>
>> On 14-11-2012 21:00, 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.
>>>
>>
>> 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.
>

Well, there's not much point in that when all compilers have intrinsics 
anyway (e.g. GDC has __sync_* and __atomic_* and LDC has some intrinsics 
in ldc.intrinsics that map to certain LLVM instructions).

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org