[cpp-threads] Somewhat relevant technical report

[Peter Dimov]

Hans Boehm wrote:
> On Sat, 17 Dec 2005, Peter Dimov wrote:
>
>> Boehm, Hans wrote:
>>> I think we're trying to say different things, and perhaps the
>>> footnote should be rephrased.
>>>
>>> We basically have, in Posix terms:
>>>
>>> T1: v1 = 1; pthread_mutex_lock(&l1);
>>>
>>> T2: pthread_mutex_trylock(&l1) fails; r2 = v1;
>>>
>>> The question is whether r2 is guaranteed to be 1.
>>>
>>> As I see it, the only reason this might not be guaranteed is that
>>> pthread_mutex_try_lock doesn't guarantee memory synchronization in
>>> this case.
>>>
>>> It's unclear what that statement means.
>>
>> To me it means exactly what it says. A failed pthread_mutex_trylock
>> is a no-op with respect to memory synchronization and visibility, a
>> { return false; }.
>>
> And then the resulting program has no data races, but insufficient
> "memory synchronization".  I'm not sure I know what the resulting
> semantics are.

It is not guaranteed to not contain data races.

T2:

if( pthread_mutex_trylock(&l1) )
{
    f();
}
else
{
    g( v1 );
}

can be transformed by a sufficiently smart compiler to

r = v1;

if( pthread_mutex_trylock(&l1) )
{
    f();
}
else
{
    g( r );
}

because it knows that the else-branch can be reordered across the trylock. 
Sufficiently smart hardware can do the same, in principle. But...

> In any case, the extra lock-unlock pair still gets us back to
> something that both has no data races and sufficient memory
> syncronization.

... I agree that the lock/unlock pair prevents this transformation.