Subj : Re: What does Memory Barriers mean ?? To : comp.programming.threads From : Joseph Seigh Date : Fri Jan 07 2005 10:00 pm On Fri, 7 Jan 2005 17:42:25 -0800, SenderX wrote: >>> 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. > In gcc, you should be able to specify "memory" in the clobber list for an inline asm memory barrier and gcc shouldn't optimize accross it. vc++ has no such provision for its inline asm unless you use all the regs so vc++ can leave anything in them. So for vc++ you have to use eax, ebx, ecx, edx, esi, and edi to force optimization off. > > > > 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? > The compiler has to know that there are no data dependencies in order to optimize, and that's a lot harder than you think. So in your example the compiler has to assume that assembly_routine_1 could store the address of p1 in global memory to be accessed later by assembly_routine_2, so it can't reorder the calls. It called the aliasing problem I believe and most compilers don't bother to optimize across calls to separately compiled external functions. About the only thing a compiler can optimize across a call are local stack variables that has never had their addresses taken. Most shared data can't be optimized since they're referenced globally or by explicit references. -- Joe Seigh .