2
votes

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?

1
If you ask about implementation of memory barriers, this implementation is compiler-specific and architecture-specific. You need to choose concrete compiler (and programming language), and look into its documentation about memory barriers. By analogy, you need to choose specific processor (or family), and look into its specification about barriers. If you failed to undestand some of these resources, you may ask more concrete question.Tsyvarev
Thanks @Tsyvarev. I looked into ARM's document, and found that it ensures ordering by stalling the CPU pipeline.user2351818

1 Answers

2
votes

@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