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