Re: What in C++11 prohibits mutex operations from being reordered?
On Wednesday, 3 April 2013 15:23:18 UTC+3, Michael Podolsky wrote:
On Apr 3, 7:17 am, =D6=F6 Tiib <oot...@hot.ee> wrote:
On Wednesday, 3 April 2013 05:30:45 UTC+3, Michael Podolsky wrote:
It can not be direct relation between "sequenced before" relation and
assembly output, otherwise we would not be allowed to reorder the
previous two relaxed atomic operations on the level of compiler. And
we are allowed.
You originally asked about mutexes, and not about "relaxed" atomic
operations. For example =A7 1.10/5 elaborates the difference.
I thought you claimed that "sequenced before" is what solely prohibits
compiler from reordering its output instructions in my example with
mutexes, so I brought an example with integers (non-volatile, of
course) and then an example with relaxed atomics to show that
"sequenced before" is not directly equivalent to the order of
instructions produced by compiler, the compiler may still reorder
instructions, even if the later "sequenced before" former.
Yeah, sorry for being unclear. I do not get what exact part of
puzzle it is then that you miss? "sequenced before" it was not
maybe "synchronizes with" or "happens before"? Mutex access can
not be reordered.
For example =A7 1.10/5 elaborates the difference.
It is not clear for me still what in this paragraph prevents mutex
operations from being reordered in my example.
Yes, =A71.10/5 only tells that atomic operations, mutexes and fences
as synchronization operations and that relaxed atomic operations *are*
*not* synchronization operations.
Maybe you should first find out how synchronization operations work?
It is tricky logic sprinkled all over the standard ... I think most
of the =A71.10, =A729.3 and =A729.8 are relevant. I try to collect *short*
and *simple* and *logical* explanation ... : If A is sequenced before
B on the same thread, and B synchronizes with C on another thread,
and C is sequenced before D on that second thread, then A happens before
D, and A and D can access the same data even if they are non-atomic
operations. So ... even ordinary 'int' access like 'i = 42' can not be
ordered to other side of m2.lock() nothing to talk of m1.unlock() or
some other synchronization operation like that.
Besides take into
account that in my original example (start of the thread) I have an
implementation of spin-locks with atomic variables and ask the same
question - what prevents these atomic operations from being reordered
by compiler.
I did not understand what your example does, sorry. Let me try to write
example that achieves some synchronization ...
// bool that tells that thread 1 is done with data. It is
// atomic just because standard does not guarantee that accesses to
// bool are atomic.
std::atomic<bool> ready(false);
// the ordinary data
int data=0;
void thread_1()
{
// these lines can't be reordered in any way
data=42;
std::atomic_thread_fence(std::memory_order_release);
ready.store(true,std::memory_order_relaxed);
}
void thread_2()
{
if(ready.load(std::memory_order_relaxed))
{
// these lines can't be reordered
std::atomic_thread_fence(std::memory_order_acquire);
std::cout<<"data="<<data<<std::endl;
}
}
The effect is that thread 2 does not touch data if thread 1
is not ready with it. So access to non-atomic "data" is safe, synchronized
and no data race is possible.