On Thursday 05 April 2007 00:48 Rana Dasgupta wrote: > On 4/4/07, Gregory Shimansky wrote: > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote: > > > On 4/4/07, Mikhail Fursov wrote: > > > > On 4/4/07, Alexey Petrenko wrote: > > > > > 2007/4/4, Gregory Shimansky : > > > > > > > > I would like to see these modifications. I wonder what you've > > > > > > > > done in > > > > > > > > > > > > port/src/thread/linux/apr_thread_ext.c and > > > > > > vmcore/include/atomics.h. They contain mfence and sfence > > > > > > instructions in inline assembly which have to be changed to > > > > > > something else on P3. > > > > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already > > > strongly ordered for writes ? > > > > What about MemoryReadWriteBarrier()? If you know, what kind of code > > should be used for this in P3? > > One of the compiler guys can confirm this. But I don't believe that > you need to worry about any of the fence instructions fence on any of > the PIII, PIV genuine intel procs unless you are using streaming mode > ( SIMD ) instructions which are weakly ordered. I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier and apr_memory_rw_barrier functions which are wrappers to mfence/sfence instructions. They aren't used in the code which uses SSE2 in any way. - The apr_memory_rw_barrier (executes mfence) function is used in thin locks implementation in threading code. - MemoryReadWriteBarrier (executes mfence) is used in org.apache.harmony.util.concurrent natives implementation after writing/reading int/long/object fields via JNI. - MemoryWriteBarrier (executes sfence) is used in classloader for fast management of classes collection and in strings pool for the same reason. In all three cases SSE2 is not involved in any way, simply loads and stores are done with the memory. According to you in all of those cases memory barriers are not needed. I am just confused then why were they inserted in those places? -- Gregory