So far as I know,both compiler and CPU can carry out instruction reordering. By 'carried out by CPU',I mean that I do not care about instruction reordering that is done by compiler and reordering that is caused by Store Buffer and CPU cache. For reordering caused by the Store Buffer and CPU Cache,which was discussed in this paper, I have already understood how memory barrier inhibit such reordering(memory reordering).
What I care is such a reordering:
Source code:
data=1; //statement1
ready=true;//statement2
But, ThreadA run on CPU0 executes the above code in the following order:
ready=true;//statement2
data=1; //statement1
That's to say the CPU reorders the instructions,which causes the actual execution order different from the order specified by source code. As we know,if we want to make the order of source code be preserved, we can resort to memory barrier(or fence),as:
New Source code:
data=1; //statement1
smp_wb();//Insert a write barrier here!
ready=true;//statement2
So here comes my question: how memory barrier inhibit instruction reordering here?
@Tsyvarev is correct, it is processor(or processor family) specific. For example, under ARM, the DMB(a memory barrier) causes a stall of the CPU pipeline to ensure ordering(prevents reordering),as its documentation said:
Figure 1 shows the DMB instruction being used to ensure memory ordering by stalling the pipeline