---
title: "Discussion on \"Using Acquire/Release Semantics in Java Atomics for Fun and Profit\" | Hashnode"
description: "Discussion on \"Using Acquire/Release Semantics in Java Atomics for Fun and Profit\". In case you've missed it, recent JDK versions include new memory semantics for atomic operations available in VarHandle and Atomic* classes. These new semantics are equivalent to C/C++'s std::memory_order. The only confusing naming convention is that..."
url: "https://hashnode.com/posts/using-acquirerelease-semantics-in-java-atomics-for-fun-and-profit/61ead6ba540e877a6c00c38a"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Using Acquire/Release Semantics in Java Atomics for Fun and Profit](https://puzpuzpuz.dev/using-acquirerelease-semantics-in-java-atomics-for-fun-and-profit?utm_source=hashnode&utm_medium=feed)

In case you've missed it, recent JDK versions include new memory semantics for atomic operations available in VarHandle and Atomic\* classes. These new semantics are equivalent to C/C++'s std::memory\_order. The only confusing naming convention is that...

Jan 21, 2022 · 5 min read · puzpuzpuz.dev  
Read the article

-   [#java](https://hashnode.com/tag/java)
-   [#concurrency](https://hashnode.com/tag/concurrency)

## Written by

[Andrei Pechkurov](https://hashnode.com/@puzpuzpuz)

@puzpuzpuz

  
[View profile](https://hashnode.com/@puzpuzpuz)

Top data race and segfault producer in the room.

Core database engineer at QuestDB. Distributed systems gazer. Node.js contributor. Occasional tech blogger and speaker.

## Responses 1

Markdown supported · ⌘↵ to post

[Peter Veentjer](https://hashnode.com/@pveentjer)

[Jan 23, 2022](https://hashnode.com/posts/using-acquirerelease-semantics-in-java-atomics-for-fun-and-profit/61ead6ba540e877a6c00c38a/comment/61ecebefa12088017fbeafce)

Keep in mind that your counter is not monotonic increasing: it can go back in time. If a thread has read the counter, and then runs into a context switch, it could be quite some time it gets back on a core. And then will add 1 to a very old counter.

There is some overlap between opaque and memory\_order\_relaxed. But there is at least 1 fundamental difference. memory\_order\_relaxed is coherent and [opaque](https://github.com/openjdk/jcstress/blob/master/jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_03_NonMCA_Coherence.java) is not.

I would also include a benchmark using opaque only. Opaque doesn't order surrounding loads/stores and hence restricts the compiler and CPU less. Probably won't be noticeable in this particular benchmark, but when you do more than only increasing a counter, it might make a difference. Also, the difference might be more visible on ARM than X86 due to its more relaxed memory model.

If you want to optimize for the writing side, I would really use some kind of striped counter like the LongAdder. So that threads don't need to contend for cache lines. And if it is purely for progress indication and performance is critical, I would explicitly give each thread its own counter line and push everything through opaque for optimal performance. The burden is completely shifted to the reader.

[Andrei Pechkurov](https://hashnode.com/@puzpuzpuz)

[Jan 23, 2022](https://hashnode.com/posts/using-acquirerelease-semantics-in-java-atomics-for-fun-and-profit/61ead6ba540e877a6c00c38a/comment/61ecebefa12088017fbeafce#reply-61ecef0da12088017fbeb09d)

Yes, monotonicity is not guaranteed on such counter. The counter is nothing more than an excuse to compare different semantics and operations.

As for LongAdder, it's mentioned in the post along with pros and cons.

Thanks for the comment on relaxed vs. Opaque. That's interesting.

[Andrei Pechkurov](https://hashnode.com/@puzpuzpuz)

[Jan 23, 2022](https://hashnode.com/posts/using-acquirerelease-semantics-in-java-atomics-for-fun-and-profit/61ead6ba540e877a6c00c38a/comment/61ecebefa12088017fbeafce#reply-61ed6178a12088017fbec0c0)

> memory\_order\_relaxed is coherent and opaque is not.

Your link demonstrates that getOpaque() is coherent (writes on the same variable are guaranteed to be observed in a total order) even on non-MCA architectures. Am I missing something here?
