Thank you very much Peter Veentjer, your answer was very clarifying. I think I should have mentioned that I was aware of fences semantics, but after your explanation I have an even better understanding. What I was really unaware of is the part you said: "So what you see in Unsafe is not what is actually being used to generate machine instructions". That was a surprise to me and the root of all my misunderstanding. After reading your answer I have checked on the internet about the "@IntrinsicCandidate" annotation and understood the whole picture. I'm gonna do the JMH test you suggested
Thanks again =) On Sun, 18 Sept 2022 at 05:43, Peter Veentjer <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdBKSLAm3v1vTsOmWVLGb5m0HaDW6zM8Z-FWx5KF_Hgw%2Bw%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/CADkjdv9Zfwn15yZbAKXMSPzsWoxMAbMFTjzfMgyMqdMOOei3ug%40mail.gmail.com.
