Something needs to happen with shared, and soon.

[Andrei Alexandrescu]

On 11/14/12 6:39 AM, Alex Rønne Petersen wrote:
> On 14-11-2012 15:14, Andrei Alexandrescu wrote:
>> On 11/14/12 1:19 AM, Walter Bright wrote:
>>> On 11/13/2012 11:56 PM, Jonathan M Davis wrote:
>>>> Being able to have double-checked locking work would be valuable, and
>>>> having
>>>> memory barriers would reduce race condition weirdness when locks
>>>> aren't used
>>>> properly, so I think that it would be desirable to have memory
>>>> barriers.
>>>
>>> I'm not saying "memory barriers are bad". I'm saying that having the
>>> compiler blindly insert them for shared reads/writes is far from the
>>> right way to do it.
>>
>> Let's not hasten. That works for Java and C#, and is allowed in C++.
>>
>> Andrei
>>
>>
>
> I need some clarification here: By memory barrier, do you mean x86's
> mfence, sfence, and lfence?

Sorry, I was imprecise. We need to (a) define intrinsics for loading and 
storing data with high-level semantics (a short list: acquire, release, 
acquire+release, and sequentially-consistent) and THEN (b) implement the 
needed code generation appropriately for each architecture. Indeed on 
x86 there is little need to insert fence instructions, BUT there is a 
definite need for the compiler to prevent certain reorderings. That's 
why implementing shared data operations (whether implicit or explicit) 
as sheer library code is NOT possible.

> Because as Walter said, inserting those blindly when unnecessary can
> lead to terrible performance because it practically murders
> pipelining.

I think at this point we need to develop a better understanding of 
what's going on before issuing assessments.


Andrei