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.
> A) the reordering of
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk