Subj : Re: What does Memory Barriers mean ?? To : comp.programming.threads From : SenderX Date : Fri Jan 07 2005 05:42 pm >> The C/C++ std shoud rip its dead brain out, and replace it with a new one >> that can actually comprehend threads and memory visibility... >> >> ;) > > No ;) required. > . I have had some compiler reordering issues a while ago when I was testing and developing the RCU algorithm that my library uses. I disassembled some key stuff and found that a hazards reference was being performed before the RCU quiescent state changed to active. MSVC++ did not reorder the instructions, but GCC on linux did. I had to create most of the RCU code in external compiled i686 assembly library just to ease my mind. Magically, the reordering of "critical" instructions never happened again. P.S. Here is a question on compiler reordering wrt C... extern void assembly_routine_1( void** ); extern void assembly_routine_2( void** ); /* code */ void *p1, *p2; 1: assembly_routine_1( &p1 ); 2: assembly_routine_2( &p2 ); Since call 2 dosen't rely on anything from call 1, could the compiler could execute call 2 before call 1? How abaout this one... /* code */ void *p1, *p2; 1: assembly_routine_1( &p1 ); 2: p2 = p1; 3: assembly_routine_2( &p2 ); The compiler knows that step 2 is reading a value that might have been changed by the external function at step 1. The compiler should execute step 1,2,3 in order? .