[concurrency-interest] If LoadLoad barrier is reduced to no-op, why lfence?
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:
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.
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest