Something needs to happen with shared, and soon.

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Nov 14 14:17:42 PST 2012


On 11/14/12 11:21 AM, Iain Buclaw wrote:
> On 14 November 2012 17:50, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org>  wrote:
>> On 11/14/12 9:15 AM, David Nadlinger wrote:
>>>
>>> On Wednesday, 14 November 2012 at 14:16:57 UTC, Andrei Alexandrescu 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.
>>>
>>>
>>> Again, this is true, but it would be a fallacy to conclude that
>>> compiler-inserted memory barriers for »shared« are required due to this
>>> (and it is »shared« we are discussing here!).
>>>
>>> Simply having compiler intrinsics for atomic loads/stores is enough,
>>> which is hardly »built into the language«.
>>
>>
>> Compiler intrinsics ====== built into the language.
>>
>> Andrei
>>
>
> Not necessarily. For example, printf is a compiler intrinsic for GDC,
> but it's not built into the language in the sense of the compiler
> *provides* the codegen for it.  Though it is aware of what it is and
> what it does, so can perform relevant optimisations around the use of
> it.

aware of what it is and what it does ====== built into the language.

Andrei



More information about the Digitalmars-d mailing list