Making operations on volatile fields atomic.

Overview

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 or 6

With volatile

Thread 2:  volatile int a = 5;

Thread 1: a = 6;

(later)

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

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 even given enough time.

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 given enough time.

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 methodsuggested syntaxnotes
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 subtractionx -= y;
Atomic divisionx /= y;
Atomic modulusx %= y;
Atomic shiftx <<= y;
Atomic shiftx >>= z;
Atomic shiftx >>>= w;
Atomic andx &= ~y;clears bits  
Atomic orx |= z;sets bits
Atomic xorx ^= 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++;
I am not convinced that a more cumbersome syntax makes it clearer as to what is happening.  Consider this example
volatile int a, b;

a += b;

or 

a.volatile.addAndGet(b.volatile);

or

AtomicInteger a, b;

a.addAndGet(b.get());

Which of these operations, as a line are atomic. Answer none of them, however systems with Intel TSX can make these atomic and if you are going to change the behaviour of any of these lines of code I would make the the a += b;  rather than invent a new syntax which does the same thing most of the time, but one is guaranteed and not the other.

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.


Comments

  1. see http://openjdk.java.net/jeps/193

    ReplyDelete
    Replies
    1. Good point. IMHO ++value is more natural than value.volatile.incrementAndGet()

      Delete
  2. Much as I may like or dislike the suggestion, I just can't see this happening. I believe history teaches us that Java is a conservative product and I find it hard to believe the syntax can be updated (in-place). The syntax (and the JDK) has been changed by addition rather than in-place modification of behaviour. This is probably why JEP-193 looks the way it does.
    A fusion of your suggestion and JEP 193 is possible by keeping your syntax but changing the declared type. For instance adding the keyword "atomic" to Java and thus allowing the above behaviour for atomic fields rather than volatile. This will allow backwards compatibility, but will add a keyword...

    ReplyDelete
    Replies
    1. This is part of my point. Changing the JMM to provide the "expected" behaviour is not going to break backward compatibility of a correctly written program and highly unlikely to break even an incorrectly written program. The only change is to provide a guarantee to behave is a manner which is consistent with how it behaves when the value is uncontested by another thread.

      Delete
    2. The point I make is that Java is a conservative environment in which making same code have a different effect (even if it is arguably a better one) is the hard thing to do. JEP 192 is cumbersome but also easily separated from existing usage.
      One addition to the JEP I would like is to remove the 'volatile' requirement. Make the syntax allow separation of fenced operations, memory access and atomicity.
      Volatile already has allot of luggage associated with it. E.g. the volatile read has 3 meanings conflated to one:
      1. An atomic read of long/double (see Shipilev's post: http://shipilev.net/blog/2014/all-accesses-are-atomic/)
      2. A read from memory(i.e prevent hoisting into a register (and out of loops), each read goes to address)
      3. A LoadLoad barrier (forcing HB and thus requiring all subsequent reads to refresh)
      Sometime just one would do...

      Delete
    3. I see your point. Perhaps it doesn't have to be a major syntax change, just different enough to have no impact on previous behaviour. Instead of an "atomic" keyword, perhaps we could have an @atomic annotation on the field. This would mean only new code with this annotation would have new behaviour.

      Delete
  3. Hi
    Shouldn't
    x.incrementAndGet() be ++x
    and
    x.getAndIncrement() be x++ ?

    ReplyDelete
  4. It seems to me that using the normal expression syntax and letting the compiler auto-detect cases when volatile operations could be "swapped in" would have the same problems as auto-vectorization in C++ compilers:

    - it would be very "finicky" - ie one (seemingly) small change would deactivate it
    - it would be "very hard" to tell (ie. you would need to look at the generated bytecode) if the proper methods are used

    Because of this I would prefer something more explicit like the JEP 193 proposes.

    ReplyDelete
    Replies
    1. I agree with your concerns. IMHO some work would need to be done to address these issues in any case, your suggestion would be easier for the JVM designer.

      Delete
    2. One way to make it clearer is to make a line which contains a volatile (and no method calls) atomic. You could even make lines with method calls atomic in future versions. You could also add a compiler warning if a line cannot be made atomic, I am not convinced something which almost works without a warning is better. ;)

      Delete
    3. I wonder if there are cases when e.g., `a++` with the volatile semantics 1. makes sense, 2. is faster than with the atomic semantics. Maybe a single thread counting and making the result visible to all others?

      Making the whole line atomic would be nice, but hardly doable without TSX, I guess. And quite often it's not what you want, like in `privateVar1 += someVolatile / privateVar2`. Or did you mean just executing the part between the first volatile read and the last volatile write atomically? But still, `volatile1 = Math.max(volatile1, volatile2)` may be fine without any atomicity when there's a single writer for each variable.

      Delete
    4. In general you can make any piece of code "transactional" with compare and swap (ie. read original, compute, C&S - repeat until success).

      The questions are:
      - Are you prepared to handle the looping? (especially if the piece of data is very contended) - C&S doesn't have any guarantees that it will succeed, although in practice it is "very, very rare" that a thread can't make progress
      - What about more complex data dependencies (ie. volatile1 and volatile2 have some kind of dependency - ie. v1 = 2*v2 - which can be violated by reading v1 before the update and v2 after the update)?

      Delete
  5. Thanks for great explanation of Volatile Variable behavior.

    ReplyDelete

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

Low Latency Microservices, A Retrospective

Unusual Java: StackTrace Extends Throwable