[cpp-threads] Memory modelcounterproposal:synchronizationoperations

[Peter Dimov]

Peter Dimov wrote:
> Boehm, Hans wrote:
>> 1) There exist mountains of code that use double-checked
>> locking or similar hacks.  (Some major vendors recommended
>> it until very recently.  And there appear to be many cases
>> in which it is critical to performance.  Thus "don't do that"
>> is not a real option.)
>>
>> 2) This code is broken, but we need to provide an easy path to
>> fix it.
>>
>> 3) __async volatile (or some alternative set of keywords)
>> would make this easy, and would allow basically the same
>> technique to work across C++, Java, and potentially C.
>
> So, basically, your argument is that __async volatile makes it easy
> to write uniformly broken code in all three languages. :-)

To expand on that a little, as it may be unclear.

Typical DCL:

X * volatile p = 0;
mutex mx;

X * get()
{
    if( p == 0 )
    {
        mx.lock();

        if( p == 0 )
        {
            p = new X;
        }

        mx.unlock();
    }

    return p;
}

Idiomatic MT C++ replacement:

X * get()
{
    /*protected*/ static X * p = new X;
    return p;
}

My Java knowledge is limited, but I believe that the idiomatic Java 
replacement is similar, using a private static final.

So all __async volatile would do in this situation is help people avoid the 
idiomatic solution provided by the language and potentially make the code 
much slower than the original.

This doesn't mean that __async volatile doesn't have its uses, just that 
fixing DCL isn't one of them, IMO. The primary value of a type that 
guarantees sequential consistency is that it allows easy (but potentially 
suboptimal) implementations of lock-free algorithms as given in the 
literature. Whether this is enough justification for the introduction of 
__async volatile is another story. (My opinion is that it is not.)