[concurrency-interest] If LoadLoad barrier is reduced to no-op, why lfence?

Nathan Reynolds nathan.reynolds at oracle.com
Fri Jul 27 13:47:48 EDT 2012


This confused me too a while back.  I had to read and re-read the 
Software Developer's Manual back then and again now.  Compare the first 
paragraphs of lfence, mfence and sfence (included below).  If I am 
interpreting it right, the mfence and sfence instructions only impact 
data loads and data stores.  The lfence instruction serializes the 
instruction stream itself.  In other words, lfence prevents instructions 
after it from executing until the lfence has retired.

For example, if the instruction stream has "lfence" followed by "inc 
eax", then the "inc eax" won't begin executing until the "lfence" 
retires.  This is interesting since "inc eax" only affects a register.

There is an interesting point in JSR-133 Cookbook.  "The x86 processors 
supporting "streaming SIMD" SSE2 extensions require LoadLoad "lfence" 
only only in connection with these streaming instructions."  That gives 
us a hint for when lfence would be useful.

http://download.intel.com/design/processor/manuals/253666.pdf
http://download.intel.com/products/processor/manual/253667.pdf

Page 3-588 Vol. 2A

LFENCE---Load Fence

Performs a serializing operation on all load-from-memory instructions 
that were issued prior the LFENCE instruction. Specifically, LFENCE does 
not execute until all prior instructions have completed locally, and no 
later instruction begins execution until LFENCE completes. In 
particular, an instruction that loads from memory and that precedes an 
LFENCE receives data from memory prior to completion of the LFENCE. (An 
LFENCE that follows an instruction that stores to memory might complete 
before the data being stored have become globally visible.) Instructions 
following an LFENCE may be fetched from memory before the LFENCE, but 
they will not execute until the LFENCE completes.

Page 3-628 Vol. 2A

MFENCE - Memory Fence

Performs a serializing operation on all load-from-memory and 
store-to-memory instructions that were issued prior the MFENCE 
instruction. This serializing operation guarantees that every load and 
store instruction that precedes the MFENCE instruction in program order 
becomes globally visible before any load or store instruction that 
follows the MFENCE instruction.1 The MFENCE instruction is ordered with 
respect to all load and store instructions, other MFENCE instructions, 
any LFENCE and SFENCE instructions, and any serializing instructions 
(such as the CPUID instruction).  MFENCE does not serialize the 
instruction stream.

Page 4-525 Vol. 2B

SFENCE - Store Fence

Performs a serializing operation on all store-to-memory instructions 
that were issued prior the SFENCE instruction. This serializing 
operation guarantees that every store instruction that precedes the 
SFENCE instruction in program order becomes globally visible before any 
store instruction that follows the SFENCE instruction. The SFENCE 
instruction is ordered with respect to store instructions, other SFENCE 
instructions, any LFENCE and MFENCE instructions, and any serializing 
instructions (such as the CPUID instruction). It is not ordered with 
respect to load instructions.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 7/27/2012 9:57 AM, Lei Zhao wrote:
> Hello Everyone,
>
>   I am currently reading the JMM cookbook 
> (http://gee.cs.oswego.edu/dl/jmm/cookbook.html) and have a (maybe 
> hardware related) question about barrier instructions: if the LoadLoad 
> barrier is going to be no-op on x86-TSO, why does lfence instruction 
> exist at all? (similarly StoreStore and sfence). I am a little 
> confused about whether x86-TSO intrinsically guarantees load-load 
> ordering or not. Thank you.
>
> - Lei
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120727/1fc90fad/attachment.html>


More information about the Concurrency-interest mailing list