Difference between set and lazySet on AtomicLong

[Antonio Rafael Rodrigues]

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?

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), If yes, can we say that set and lazySet on AtomicInteger have the same effects?

Thanks

[Peter Veentjer]

On Sun, Sep 18, 2022 at 9:24 AM Antonio Rafael Rodrigues <antonio....@gmail.com> 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 mechanical-symp...@googlegroups.com.
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.

[Peter Veentjer]

This is also a very good read for your particular question:

https://shipilev.net/blog/2014/on-the-fence-with-dependencies/

[Peter Veentjer]

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.

[Antonio Rafael Rodrigues]

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 =)

To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdBKSLAm3v1vTsOmWVLGb5m0HaDW6zM8Z-FWx5KF_Hgw%2Bw%40mail.gmail.com.