Making Operations on Volatile Fields Atomic

Peter Lawrey

Jun. 27, 14 · Interview

Likes (0)

Comment

Save

11.5K Views

The expected behaviour for volatile fields is that they should behave in a multi-threaded application the same as they do in a single threaded application. They are not forbidden to behave the same way, but they are not guaranteed to behave the same way.

The solution in Java 5.0+ is to use AtomicXxxx classes however these are relatively inefficient in terms of memory (they add a header and padding), performance (they add a references and little control over their relative positions), and syntactically they are not as clear to use.

IMHO A simple solution if for volatile fields to act as they might be expected to do, the way JVM must support in AtomicFields which is not forbidden in the current JMM (Java- Memory Model) but not guaranteed.

Why make fields volatile?

The benefit of volatile fields is that they are visible across threads and some optimisations which avoid re-reading them are disabled so you always check again the current value even if you didn't change them.

e.g. without volatile

Thread 2:  int a = 5;
Thread 1:  a = 6;

(later)

Thread 2: System.out.println(a); // prints 5

With volatile

Thread 2:  volatile int a = 5;
Thread 1: a = 6;

(later)

Thread 2: System.out.println(a); // prints 6

Why not use volatile all the time?

Volatile read and write access is substantially slower. When you write to a volatile field it stalls the entire CPU pipeline to ensure the data has been written to cache. Without this, there is a risk the next read of the value sees an old value, even in the same thread (See AtomicLong.lazySet() which avoids stalling the pipeline)

The penalty can be in the order of 10x slower which you don't want to be doing on every access.

What are the limitations of volatile?

A significant limitation is that operations on the field is not atomic, even when you might think it is. Even worse than that is that usually, there is no difference. I.e. it can appear to work for a long time even years and suddenly/randomly break due to an incidental change such as the version of Java used, or even where the object is loaded into memory. e.g. which programs you loaded before running the program.

e.g. updating a value

Thread 2: volatile int a = 5;

Thread 1: a += 1;

Thread 2: a += 2;

(later)

Thread 2: System.out.println(a); // prints 6, 7 or 8

This is an issue because the read of a and the write of a are done separately and you can get a race condition. 99%+ of the time it will behave as expect, but sometimes it won't/

What can you do about it?

You need to use AtomicXxxx classes. These wrap volatile fields with operations which behave as expected.

Thread 2: AtomicInteger a = new AtomicInteger(5);

Thread 1: a.incrementAndGet();

Thread 2: a.addAndGet(2);

(later)

Thread 2: System.out.println(a); // prints 8

What do I propose?

The JVM has a means to behave as expected, the only surprising thing is you need to use a special class to do what the JMM won't guarantee for you. What I propose is that the JMM be changed to support the behaviour currently provided by the concurrency AtomicClasses.

In each case the single threaded behaviour is unchanged. A multi-threaded program which does not see a race condition will behave the same. The difference is that a multi-threaded program does not have to see a race condition but changing the underlying behaviour

current method	suggested syntax	notes
x.getAndIncrement()	x++ or x += 1
x.incrementAndGet()	++x
x.getAndDecrment()	x-- or x -= 1
x.decrementAndGet()	--x
x.addAndGet(y)	(x += y)
x.getAndAdd(y)	((x += y)-y)
x.compareAndSet(e, y)	(x == e ? x = y, true : false)	Need to add the comma syntax used in other languages.

These operations could be supported for all the primitive types such as boolean, byte, short, int, long, float and double. Additional assignment operators could be supported such as

current method	suggested syntax	notes
Atomic multiplication	x *= 2;
Atomic subtraction	x -= y;
Atomic division	x /= y;
Atomic modulus	x %= y;
Atomic shift	x <<= y;
Atomic shift	x >>= z;
Atomic shift	x >>>= w;
Atomic and	x &= ~y;	clears bits
Atomic or	x \|= z;	sets bits
Atomic xor	x ^= w;	flips bits

What is the risk?

This could break code which relies on these operations occasionally failing due to race conditions.

It might not be possible to support more complex expressions in a thread safe manner. This could lead to surprising bugs as the code can look like the works, but it doesn't. Never the less it will be no worse than the current state.

JEP 193 - Enhanced Volatiles

There is a JEP 193 to add this functionality to Java. An example is;

class Usage {
    volatile int count;
    int incrementCount() {
        return count.volatile.incrementAndGet();
    }
}

IMHO there is a few limitations in this approach.

The syntax is fairly significant change. Changing the JMM might not require many changes the the Java syntax and possibly no changes to the compiler.
It is a less general solution. It can be useful to support operations like volume += quantity; where these are double types.
It places more burden on the developer to understand why he/she should use this instead of x++;

Conclusion

Much of the syntactic and performance overhead of using AtomicInteger and AtomicLong could be removed if the JMM guaranteed the equivalent single threaded operations behaved as expected for multi-threaded code.

This feature could be added to earlier versions of Java by using byte code instrumentation.

Java (programming language) Race condition Data Types Syntax (programming languages) application Memory (storage engine)

Published at DZone with permission of Peter Lawrey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

Trending

Making Operations on Volatile Fields Atomic

Why make fields volatile?

What are the limitations of volatile?

What can you do about it?

What do I propose?

What is the risk?

JEP 193 - Enhanced Volatiles

Conclusion

Related

Partner Resources