Java Volatile is Powerful

Author : Pavitar Singh

Java supports two intrinsic concurrency mechanisms “synchronized” and “volatile”. We tend to use synchronized or its newer avatar “locks” from java.util.concurrent most of the times without even checking if volatile or some other option could have been a fit. A careful analysis from concurrency perspective could yield a much smarter and performant solution in many of these scenarios. This analysis would need a good understanding of the properties of each of this mechanism, some of the guarantees that they hold and how it impacts a typical program.

This article takes a look from a Java perspective at some of these semantics and guarantees and does a comparison between synchronized and volatile on some of these parameters. I am also going to go over usages of volatile to build highly performant concurrent programs.

Properties of Concurrent Programs :

A.) Visibility : It determines when actions of one Thread can be seen by the other.
It guarantees whether results of one action can be seen by another action, where both actions can be performed by different Threads.

For Example:

private boolean status;

public void setValue(boolean status){
this.status = status;
}

public boolean getValue(){
return this.status;
}
a.) Thread 1 does setValue
b.) Thread 2 does getValue

Will both Threads see the same value? In order to answer this question we need visibility guarantees which will ensure that value set by
Thread 1 will be visible when Thread 2 does getValue.

B.) Atomicity : It determines whether a set of actions occur indivisibly.
It is also possible that what seems like one action from the language perspective is actually multiple actions in the actual implementation (like incrementing a counter). Atomicity can be enforced on a sequence of actions. Unlike the transactional world it is not about success or failure of the steps, but more about their result being visible together.

C.) Ordering : It determines when actions of one Thread seem to happen out of order to other Threads.
Compilers and Processors do a lot of optimizations which end up reordering the way instructions are executed. But concurrent programs need some
guarantees which restrict some reorderings.

For Example :

void threadOne() {
a = true;
b = true;
}

boolean threadTwo() {
boolean r1 = b; // sees true
boolean r2 = a; // sees false
}

Thread One sets a and b both to true and Thread two can see true for b but false for a.

As compiler or processor may do some reordering like:

void threadOne() {
b = true;
a = true;
}

boolean threadTwo() {
boolean r1 = b; // sees true
boolean r2 = a; // sees false
}

Comparison of synchronized and volatile

We need to see what Java Memory Model has to say about these properties for synchronized and volatile. Guarantees provided by Java Memory Model are centred around Happens Before Relationship( Def: “Two actions can be ordered by a happens-before relationship.
If one action happens before another, then the first is visible to and ordered before the
second”). And according to Java Memory Model :

a.)An unlock on a monitor happens before every subsequent lock on that monitor.
b.)A write to a volatile field happens before every subsequent read of that volatile.

That means volatile and synchronized are going to have same visibility guarantees.

Now question comes about Orderings.For that again we need to look into JMM. If we look into JMM section 6.4 we find following statement :

“It is generally legal to reorder a normal memory access and a following acquire action, or a release action and a following normal memory access. This has been referred to as “roach motel” semantics: variable accesses can be moved into a synchronized block, but cannot, in general, move out.“

And the same section says : “Some operations (e.g., writing a volatile variable, unlocking a monitor, starting a thread) have release semantics.Other operations (e.g., reading a volatile variable,locking a monitor) have acquire semantics”

That means volatile and synchronized have same ordering semantics.

So Volatile doesn’t have Atomicity properties.That means we cannot enforce a sequence of actions to occur atomically with volatiles.

For Example :


volatile int i;

someMethod(){
i++;
}

Here i++ is not a single instructions its basically 3 instructions :
i.) Read i
ii.) Increment i
iii.) Set i

These 3 instructions may not happen atomically.

Thats what make volatile unfit for Counters.

But that still keeps open a lot of other use cases of volatile. Some of these patterns are nicely presented by Brian Goetz here.

I am not going to repeat these patterns, but what I have tried to stress on is the similarity of memory model semantics between volatile and synchronized, other then mutual exclusion (Atomicity is mutual exclusion) and show how these properties has been leveraged in some Java Library Classes to build performant solutions.

We find one of the smartest usages in ConcurrentHashMap which uses volatile properties (as described above) to achieve read (get method) without Locking.

If you will look into the source code you will find that the get method of ConcurrentHashMap is lock free and volatile is used to enforce memory flushes.Now here question comes why in first place we need get method to have any lock.What are guarantees from JMM perspective we are looking for while reading the data. So the answer which should come to our mind is Visiblity, whether changes made in put will be visible in get.As if they are not visible then lot of things can go wrong. So we need Visiblity guarantee in read method. Think more and you will realize other guarantee which we need is ordering. But Why ? When we see visibility its mainly provided by memory barrier being placed at (monitor release/volatile write).But then some variable write instructions can jump over the barrier and they may not be visible in read. So we need ordering guarantee also.

Now if we look into the ConcurrentHashMap source code, we see writes to volatile is happening at the end of put method and same volatile is being read first in get method. This is enforcing Visiblity and Ordering Guarantees which we needed in get method.

count is a volatile variable

V put(K key, int hash, V value, boolean onlyIfAbsent) {
lock();
try {
…
…
…
count = c; // write-volatile
}
return oldValue;
} finally {
unlock();
}
}

As you might have noticed in ConcurrentHashMap, method “put” sets count to a new value which is nothing but a volatile – write which will enforce a memory flush and also enforce ordering and no variable writes can move below it.


V get(Object key, int hash) {
if (count != 0) { // read-volatile
HashEntry e = getFirst(hash);


Now if you will see “get” method, we are reading value of count which is volatile-read.Which means whatever variables will be changed in put method will be visible in get method.

Once again reiterating According to Java Memory Model:
Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire.
Effectively, the semantics of volatile have been strengthened substantially, almost to the level of synchronization. Each read or write of a volatile field acts like “half” a synchronization, for purposes of visibility.

Performance Check:

Test Scenario:
1. 8 Threads writing/reading to a ConcurrentHashMap doing 100,000 operations

Ran the Test for ConcurrentHashMap and on a Modified ConcurrentHashMap where i removed count as a volatile and used locks in read method.

As you can see from the Chart that using volatile rather then a lock had significant performance improvements. So volatile if used smartly can be used to build highly performant concurrent application. Thanks to Doug Lea for showing us how volatile can be smartly used.

Another aspect of volatile which i wanted to explain:

A thumb rule which many of us believe is that volatiles make more sense when reads outnumber writes. However, I have always wondered if writes are more, does volatile still give us some benefits, so I thought I will try a test scenario where I vary write percentages and see how volatile performs when Writes outnumber Reads in comparison to synchronized, Locks and Atomic Variables.

Test Scenario:
1. 8 Threads doing 100,000 operations (read and write) on a Volatile,Synchronized,Atomic

As you can see from the Chart that it’s not true that Volatile should be only used when Reads outnumber Writes.

Source code of above tests can be downloaded from here.

---

Possibly related posts: (automatically generated)

• Java: volatile and synchronized
• Who ordered sequential consistency?
• Synchronized as volatile replacement: part I