Something needs to happen with shared, and soon.

David Nadlinger see at klickverbot.at
Thu Nov 15 15:12:15 PST 2012


On Thursday, 15 November 2012 at 22:58:53 UTC, Andrei 
Alexandrescu wrote:
> On 11/15/12 2:18 PM, David Nadlinger wrote:
>> On Thursday, 15 November 2012 at 16:43:14 UTC, Sean Kelly 
>> wrote:
>>> On Nov 15, 2012, at 5:16 AM, deadalnix <deadalnix at gmail.com> 
>>> wrote:
>>>>
>>>> What is the point of ensuring that the compiler does not 
>>>> reorder
>>>> load/stores if the CPU is allowed to do so ?
>>>
>>> Because we can write ASM to tell the CPU not to. We don't 
>>> have any
>>> such ability for the compiler right now.
>>
>> I think the question was: Why would you want to disable 
>> compiler code
>> motion for loads/stores which are not atomic, as the CPU might 
>> ruin your
>> assumptions anyway?
>
> The compiler does whatever it takes to ensure sequential 
> consistency for shared use, including possibly inserting fences 
> in certain places.
>
> Andrei

How does this have anything to do with deadalnix' question that I 
rephrased at all? It is not at all clear that shared should do 
this (it currently doesn't), and the question was explicitly 
about Walter's statement that shared should disable compiler 
reordering, when at the same time *not* inserting barriers/atomic 
ops. Thus the »which are not atomic« qualifier in my message.

David


More information about the Digitalmars-d mailing list