[cpp-threads] Sequential Consistency redux

N.M. Maclaren nmm1 at cam.ac.uk
Tue Nov 22 09:12:51 GMT 2011


On Nov 22 2011, Boehm, Hans wrote:
>> From: Alan Stern
>> 
>> (On the other hand, even now I think the text could stand a little more
>> clarification.  1.10p8 says "All operations on a given mutex occur in a
>> single total order", but it doesn't say explicitly that this order must
>> be consistent with "happens before".  Contrast this with the way 1.10p6
>> talks about the relation between an atomic object's modification order
>> and "happens before".)
>
> Again, I don't see how this could fail to be satisfied. I don't believe 
> there is a way to get a cycle in happens-before union mutex-order without 
> violating the other constraints. The other constraints on mutexes are 
> such that mutex-order is a subset of happens-before. (Outermost acquires 
> and releases must alternate. The acquire -> release edges contribute to 
> sequenced before, and release -> acquire contribute to 
> synchronizes-with.)

I should be interested what constraints you think my example fails on, if
you are NOT using 1.10p12.  I spent quite a long time searching, and
couldn't find anything - I was being a bit clueless in not realising the
relevance of 1.10p12, but that's another matter :-)  To save you looking
back, here it is again:

    In serial code:
        static mutex A, B;
        int a = 0, b = 0;
    The program then creates 4 threads.
    In thread 1:
        A.lock(); a = 1; A.unlock();
    In thread 2:
        B.lock(); b = 1; B.unlock();
    In thread 3:
        A.lock(); cout << a << endl; A.unlock();
        B.lock(); cout << b << endl; B.unlock();
    In thread 4:
        B.lock(); cout << b << endl; B.unlock();
        A.lock(); cout << a << endl; A.unlock();

Regards,
Nick Maclaren.




More information about the cpp-threads mailing list