why critical regions can shields you from all of these reordering issues?

Question

I saw a sentence from the  chapter 10 " Memory Models and Lock Freedom" of the book "Concurrent Programming on Windows"written by Joe Duffy :http://www.amazon.com/Concurrent-Programming-Windows-Architecture-Development/dp/032143482X

t0
x = 1 ;
a = y ;

t1
y = 1 ;
b = x

Is i t possible that a = = b = = 0 after threads to and tl have both run once?  the answer is yes, because the above code can be  reorder to the following code:

t0
a = y ;
x = 1 ;

t1
b = x ;
y = 1 ;

this result obviously not the result which you expected, So how to prevent this result happened? his solution is using the Critical Regions.

the following is excerpted  from the chapter 10:

"Critical Regions as Fences
Using critical regions shields you from all of these reordering issues. That's because critical region primitives, such as Win32's critical section and the CLR's monitor, work with the compiler, CPU, and memory system to prevent problematic instruction reordering from happening. All correctly written synchronization primitives do this. If the example above was written to use critical regions, no reordering may legally affect the end result.

t0
Enter_c r it i c a l_region ( ) ;
x = 1 ;
a = y ;
Leave_c rit i c a l_regio n ( ) ;

t1
Enter_c rit i c a l_region ( ) ;
y = 1 ;
b = x ;
Lea ve_c r it i c a l_region ( ) ;

"

http://www.albahari.com/threading/part4.aspx#_Memory_Barriers_and_Volatility

and also based on Joseph Albahari's article "Threading in C#" in the above URL,

"Memory barriers and locking

As we said earlier, Monitor.Enterand Monitor.Exit both generate full fences. So if we ignore a lock’s mutual exclusion guarantee, we could say that this:
lock (someField) { ... }

is equivalent to this:
Thread.MemoryBarrier();{...}Thread.MemoryBarrier();
"

based on Joe's words in his book, the lock /Monitor is the  critical region of the CRL world,So the  above code can be convert to the following :

t0
Thread.MemoryBarrier();
x = 1 ;
a = y ;
Thread.MemoryBarrier();

t1
Thread.MemoryBarrier();
y = 1 ;
b = x ;
Thread.MemoryBarrier();

Based on the above theories ,I think the x = 1 ; a = y ; or the y = 1 ; b = x ; still can be swapped to the following code  because  there is still  no fence between each of the two assignments in t0 ort1

t0

Thread.MemoryBarrier();
a = y ;
x = 1 ;
Thread.MemoryBarrier();

t1
Thread.MemoryBarrier();
b = x ;
y = 1 ;
Thread.MemoryBarrier();

So if it is the case ,it is still possible that a = = b = = 0 after threads to and tl have both run once even Using thecritical regions ,So I don't think critical regions technology can  shields you from all of these reordering issues ,what's your option? 

Answer 1

Critical regions do more than just apply fences: they also provide mutual exclusion, meaning that the regions can't run concurrently and will instead be serialized, with one thread not entering its region until the other thread has exited its region.

Answer 2

Hi Stephen,

thank you for your replay.

Maybe my description is not clear .So I try to describe it more clearly.

My concern is if the Critical region can prevent the instruction reordering  problem happening?that is to say if it can prevent  a = = b = = 0 happening .

maybe I misunderstood the meaning in the book,

does the critical regions in the t0 and t1 refer to the same Critical region  instead of different Critical region ?

that is to say if I want to implement the critical region described in his book with C# code, we should lock the same object ,that is to say,it should be the following code1 instead of code2 ,Right?

     

//code 1
static readonly object locker= new object();

t0
lock (locker)
     {
      x = 1 ;
      a = y ;
     }

t1
lock (locker)
     {      
      y = 1 ;
      b = x ;
     }

//code 2
 static readonly object locker1= new object();
static readonly object locker2= new object();
 
t0
lock (locker1)
     {
      x = 1 ;
      a = y ;
     }
 
t1
 lock (locker2)
     {     
      y = 1 ;
      b = x ;
     }

The code1 can prevent output  a = = b = = 0 happening even having instruction reorder,but the code2 cannot ,right?

Answer 3

re: "does the critical regions in the t0 and t1 refer to the same Critical region  instead of different Critical region ?"

Yes, the same.

Answer 4

Hello Stephen ,

I really felt honored for getting the help from the expert coming from MS Parallel Extensions team:-)

Thank you for spending the time for helping me ,Thank You So Much.