Andres Freund <andres@anarazel.de> writes:
> On Friday 19 November 2010 18:46:00 Tom Lane wrote:
>> I poked around in the Intel manuals a bit. They do have mfence (also
>> lfence and sfence) but so far as I can tell, those are only used to
>> manage loads and stores that are issued by special instructions that
>> explicitly mark the operation as weakly ordered. So the reason we're
>> not seeing bugs is presumably that C compilers don't generate such
>> instructions.
> Well. Some memcpy() implementations use string (or SIMD) operations which are
> weakly ordered though.
I'd expect memcpy to msync at completion of the move if it does that
kind of thing. Otherwise it's failing to ensure that the move is really
done before it returns.
> "
> For the Intel486 and Pentium processors, the LOCK# signal is always asserted
> on the bus during a LOCK operation, even if the area of memory being locked is
> cached in the processor. For the P6 and more recent processor families, if
> the area of memory being locked during a LOCK operation is cached in the
> processor that is performing the LOCK operation as write-back memory and is
> completely contained in a cache line, the processor may not assert the LOCK#
> signal on the bus. Instead, it will modify the memory location internally and
> allow it’s cache coherency mechanism to ensure that the operation is carried
> out atomically. This operation is called “cache locking.” The cache coherency
> mechanism automatically prevents two or more processors that have cached the
> same area of memory from simultaneously modifying data in that area.
> "
Like it says, the cache coherency mechanism prevents this from being a
problem for us. Once the change is made in a processor's cache, it's
the cache's job to ensure that all processors see it --- and on Intel
architectures, the cache does take care of that.
regards, tom lane