Is the += operator thread-safe in Java?
Solution 1:
No. The +=
operation is not thread-safe. It requires locking and / or a proper chain of "happens-before" relationships for any expression involving assignment to a shared field or array element to be thread-safe.
(With a field declared as volatile
, the "happens-before" relationships exist ... but only on read and write operations. The +=
operation consists of a read and a write. These are individually atomic, but the sequence isn't. And most assignment expressions using =
involve both one or more reads (on the right hand side) and a write. That sequence is not atomic either.)
For the complete story, read JLS 17.4 ... or the relevant chapter of "Java Concurrency in Action" by Brian Goetz et al.
As I know basic operations on primitive types are thread-safe ...
Actually, that is an incorrect premise:
- consider the case of arrays
- consider that expressions are typically composed of a sequence of operations, and that a sequence of atomic operations is not guaranteed to be atomic.
There is an additional issue for the double
type. The JLS (17.7) says this:
"For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write."
"Writes and reads of volatile long and double values are always atomic."
In a comment, you asked:
So what type I should use to avoid global synchronization, which stops all threads inside this loop?
In this case (where you are updating a double[]
, there is no alternative to synchronization with locks or primitive mutexes.
If you had an int[]
or a long[]
you could replace them with AtomicIntegerArray
or AtomicLongArray
and make use of those classes' lock-free update. However there is no AtomicDoubleArray
class, or even an AtomicDouble
class.
(UPDATE - someone pointed out that Guava provides an AtomicDoubleArray
class, so that would be an option. A good one actually.)
One way of avoiding a "global lock" and massive contention problems might be to divide the array into notional regions, each with its own lock. That way, one thread only needs to block another thread if they are using the same region of the array. (Single writer / multiple reader locks could help too ... if the vast majority of accesses are reads.)
Solution 2:
Despite of the fact that there is no AtomicDouble
or AtomicDoubleArray
in java, you can easily create your own based on AtomicLongArray
.
static class AtomicDoubleArray {
private final AtomicLongArray inner;
public AtomicDoubleArray(int length) {
inner = new AtomicLongArray(length);
}
public int length() {
return inner.length();
}
public double get(int i) {
return Double.longBitsToDouble(inner.get(i));
}
public void set(int i, double newValue) {
inner.set(i, Double.doubleToLongBits(newValue));
}
public void add(int i, double delta) {
long prevLong, nextLong;
do {
prevLong = inner.get(i);
nextLong = Double.doubleToLongBits(Double.longBitsToDouble(prevLong) + delta);
} while (!inner.compareAndSet(i, prevLong, nextLong));
}
}
As you can see, I use Double.doubleToLongBits
and Double.longBitsToDouble
to store Doubles
as Longs
in AtomicLongArray
. They both have the same size in bits, so precision is not lost (except for -NaN, but I don't think it is important).
In Java 8 the implementation of add
can be even easier, as you can use accumulateAndGet
method of AtomicLongArray
that was added in java 1.8.
Upd: It appears that I virtually re-implemented guava's AtomicDoubleArray.
Solution 3:
Even the normal 'double' data type is not thread-safe (because it is not atomic) in 32-bit JVMs as it takes eight bytes in Java (which involves 2*32 bit operations).
Solution 4:
As it's already explained, this code is not thread safe. One possible solution to avoid synchronization in Java-8 is to use new DoubleAdder
class which is capable to maintain the sum of double numbers in thread-safe manner.
Create array of DoubleAdder
objects before parallelizing:
DoubleAdder[] adders = Stream.generate(DoubleAdder::new)
.limit(typeCount).toArray(DoubleAdder[]::new);
Then accumulate the sum in parallel threads like this:
for(int type = 0; type < typeCount; type++)
adders[type].add(parts[type]);
}
Finally get the result after parallel subtasks finished:
double[] result = Arrays.stream(adders).mapToDouble(DoubleAdder::sum).toArray();