I want to add one clarification because I should have expressed myself better.
So a volatile store can't be reordered with a newer volatile load to a different address. That is why you need to have a [StoreLoad] fence. But a release store can be reordered with a newer acquire load to a different address. On Sun, Sep 18, 2022 at 10:36 AM Peter Veentjer <[email protected]> wrote: > This is also a very good read for your particular question: > > https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ > > On Sun, Sep 18, 2022 at 10:31 AM Peter Veentjer <[email protected]> > wrote: > >> >> >> On Sun, Sep 18, 2022 at 9:24 AM Antonio Rafael Rodrigues < >> [email protected]> wrote: >> >>> Hello >>> >>> I have two questions. >>> >>> 1) >>> As we can see in the source code of AtomicLong, there should be a >>> difference between calling set and lazySet, given that *set* calls >>> Unsafe.putLongVolatile and *lazySet* calls Unsafe.putLongRelease, but >>> looking at Unsafe source code, we can see that Unsafe.putLongRelease simply >>> calls Unsafe.putLongVolatile. >>> So, may I conclude that calling set and lazySet on AtomicLong have the >>> same affects? >>> >> >> A putLongRelease has much weaker semantics than a putLongVolatile. >> >> A putLongRelease store can be reordered with a newer load to a different >> address. On the X86 this can happen due to store buffers. >> >> A putLongVolatile can't be reordered with a newer load to a different >> address. On the X86 using e.g. an MFENCE after the store or a cheaper lock >> prefixed instruction like 'lock addl $0x0,(%rsp)' does the trick. See the >> following post for more detail: >> >> >> https://web.archive.org/web/20110620202202/https://blogs.oracle.com/dave/entry/instruction_selection_for_volatile_fences >> >> Apart from that, the compiler is also more constrained with a volatile >> store compared to a release store. >> >> Even though the code in the Unsafe for both methods is the same (since >> something weaker can always be upgraded to something more restrictive) they >> will lead to different machine code due to different intrensics. So what >> you see in Unsafe is not what is actually being used to generate machine >> instructions. >> >> >>> >>> 2) >>> In AtomicInteger class, set just sets a value in a volatile variable, >>> and lazySet calls Unsafe.putIntRelease, this one calls putIntVolatile. >>> Question: putIntVolatile has the same effects of setting a volatile >>> variable (I think so), >>> >> >> Yes >> >> >>> If yes, can we say that set and lazySet on AtomicInteger have the same >>> effects? >>> >> >> No. lazySet has same semantics as a release store and hence is much >> weaker than a set (which is equal to a volatile store). >> >>> >>> Thanks >>> >> >> Make a JMH test and have a look at the generated assembly and you will >> see the difference between a volatile store and a release store. >> >> >>> >>> >>> >>> >>> -- >>> 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/CADkjdv8vbF%2B3d9Am5diRmcJ-1Sbix%2BPqXB5AfhE%2B%3DapzKP2LAw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/mechanical-sympathy/CADkjdv8vbF%2B3d9Am5diRmcJ-1Sbix%2BPqXB5AfhE%2B%3DapzKP2LAw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/CAGuAWdBKSLAm3v1vTsOmWVLGb5m0HaDW6zM8Z-FWx5KF_Hgw%2Bw%40mail.gmail.com.
