Re: [boost] [lockfree] review

Subject: Re: [boost] [lockfree] review
From: Peter Dimov (pdimov_at_[hidden])
Date: 2011-08-30 04:56:44

Gottlob Frege wrote:
> Good question.  I think the question at hand (or in my mind) is
> whether atomic<Foo>, implemented with an internal mutex, is valid.

It is.

> Given
>
> A) the reordering of
>
> m1.lock();
> x1++;
> m1.unlock();
>
> m2.lock();
> x2++;
> m2.unlock();
>
> to
>
> m1.lock();
> m2.lock();
> x2++;
> x1++;
> m1.unlock();
> m2.unlock();

This reordering is invalid, by the way, which is why Alexander has been 
careful to use "multi_lock". If you add a second example that locks/unlocks 
m2 first, then m1, and reorder it in the same way, the reordered example can 
deadlock, and the original cannot. It somewhat depends on what you mean by 
reordering though. It's probably true that an observer thread can see the 
memory effects of the operations in the order m1.lock/m2.lock/x2++/x1++ by 
using acquire loads (or maybe try_lock, assuming that it doesn't fail 
spuriously, which it's allowed to do) on the control variables of m1 and m2 
and on x1 and x2, but this is not the same as reordering on the thread 1's 
side, whether by the compiler or by the hardware.

Either way, the C++MM doesn't "think" in terms of reorderings, it specifies 
behavior of multithreaded programs. If you really think that atomic<Foo>, 
implemented with a mutex, is not sequentially consistent, there must exist 
an example (a multithreaded program) containing atomic<Foo> for which the 
memory model allows an outcome which is not SC.