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

Boehm, Hans hans.boehm at hp.com
Fri Jul 27 14:36:33 EDT 2012

As far as I can tell, SFENCEs are usually needed at least after non-temporal stores like MOVNTQ, to hide the non-TSO properties of those instructions.

I haven't figured out a use for LFENCE instructions with WB cacheable memory and non-privileged instructions.  (And I haven't looked at interactions with privileged instructions.)  I don't currently understand the ordering properties of the other x86 mapping types.  I suspect it may be more useful with some of those.


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Vitaly Davidovich
Sent: Friday, July 27, 2012 10:25 AM
To: Lei Zhao
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] If LoadLoad barrier is reduced to no-op, why lfence?

There are SSE write combining instructions that don't provide the same order guarantee that write-back memory ones do (the typical mov instruction) - this is where lfence would be needed.


Sent from my phone
On Jul 27, 2012 1:03 PM, "Lei Zhao" <leizhao833 at gmail.com<mailto:leizhao833 at gmail.com>> 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<mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120727/34acd777/attachment-0001.html>

More information about the Concurrency-interest mailing list