[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