FWIW, I’ve only seen lfence used precisely in the 2 cases mentioned in this thread: 1) use of non-temporal loads (ie weak ordering, normal x86 guarantees go out the window) 2) controlling execution of non-serializing instructions like rdtsc
I’d be curious myself to hear of other cases. On Fri, Oct 4, 2019 at 10:10 AM Peter Veentjer <[email protected]> wrote: > I'm have been checking out the new fence API's in Java (Unsafe/VarHandle). > > I understand how the higher level API are translated to the logical > fences. E.g. release fence -> LoadStore+StoreStore. There are some great > post including > > https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ > Great explanation how a release fence needs to be combined with a > StoreLoad to preserve sequential consistency > > Also this post is great on the topic: > https://preshing.com/20120913/acquire-and-release-semantics/ > > When I zoom into hardware things are a bit more blurry. > > X86 provides the following guarantees: > Loads won't be reordered with older loads [LoadLoad] > Stores won't be reordered with older stores (TSO) [StoreStore] > Stores won't be reordered with older loads [LoadStore] > > One fundamental fence is the MFENCE because it will provide StoreLoad > semantics. And on X86 the Unsafe.fullFence can be compiled to a MFENCE (in > practice it uses the lock addl ... but that isn't relevant for this > discussion). This will prevent stores to be reordered with older stores and > will make sure the memory is visible to other CPU's (by waiting for the > store buffer to be drained). > I think you meant “prevent stores to be reordered with *later loads*”. In fact, awaiting store buffer drain is how it prevents the later load from reordering with an earlier store - the load can’t retire (maybe not even issue) while the store is sitting in the buffer (which would cause the load-before-store reordering to be observed). > > The SFENCE was a bit more obscure to be because X86 proves TSO; so what is > the point of adding a [StoreStore] fence is the platform provides it out of > the box (so prevents stores to be reordered with older stores). Apparently > there are certain instructions like those of SSE that are weakly ordered > and these need to have this SFENCE. Ok. I can live with that. > > But the LFENCE I can't place. Initially I thought it would provide a > similar fix as the SFENCE; so prevent load load reordering for weakly > ordered instructions like those of SSE. But apparently the LFENCE is a very > different beast. > > Could someone shed some light on the purpose of the LFENCE? > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/52527501-bffd-4a82-96fa-3fa618bec111%40googlegroups.com > <https://groups.google.com/d/msgid/mechanical-sympathy/52527501-bffd-4a82-96fa-3fa618bec111%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37EgmyMVW7p25ZejeM1EUiLoGTxExjVvjjeBG8KTzHAJ%2BA%40mail.gmail.com.
