Enterprise Integration Zone is brought to you in partnership with:

Peter is a DZone MVB and is not an employee of DZone and has posted 157 posts at DZone. You can read more from them at their website. View Full User Profile

Making Operations on Volatile Fields Atomic

06.27.2014
| 6478 views |
  • submit to reddit

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.
Published at DZone with permission of Peter Lawrey, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Valery Silaev replied on Sat, 2014/06/28 - 6:04pm

Peter,

How about this idea:

1. Add a new set of bytecode instructions for corresponding atomic operations (that probably have one-to-one mapping with atomic instructions of modern processors)

2. Introduce a "synchronized volatile" modifiers' combo on instance/class field that force compiler to produce the aforementioned instructions.

Any compatibility issues the change may raise would affect bytecode modification tools only, all legacy sources/binaries would not be affected.

Thomas Whitmore replied on Sun, 2014/06/29 - 7:05pm

I agree, it could be useful for modifications to "volatile" fields being atomic. 

JEP-193 and Peter's proposed solutions seem fairly complex, I think all we need is increment/ decrement and +=/ -= operators to work reliably. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.