29

If I have code like this -

long x;
x  = 0xFFFFFFFFL;


If i run this code on a 32 bit machine is it guaranteed to be atomic or is it possible that a different thread reading x, might get an incomplete/garbage value?

pdeva
  • 43,605
  • 46
  • 133
  • 171

4 Answers4

55

Here is the short summary:

  • For references, reads/writes are ALWAYS atomic (even in 64 bit implementations!)
  • For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic
  • For double and long, if they're volatile, reads/writes are ALWAYS atomic

Therefore there is only exception where reads/writes may not be atomic:

  • For double and long, if they're NOT declared volatile, they're NOT GUARANTEED to be atomic

So as far as atomicity of reading/writing shared data is concerned, you only need to make volatile any double or long. Everything else is already guaranteed to be atomic, regardless of how many bits are used in actual implementation.

On the specification

Here's the relevant section reproduced here for quick reference:

JLS 17.7 Non-atomic Treatment of double and long

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.

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. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values.

VM implementors are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

See also

Related questions

Community
  • 1
  • 1
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • 3
    It seems that the javadoc assumes a 32-bit system that runs the JVM. If a 64-bit JVM runs on a 64-bit system, the read/writes of long and double, which are 64-bit, can be made atomic, at least in theory, right? I know we should still right code defensively to make it backward compatible to 32-bit systems, which implies that at long as there are 32-bit systems being used, we will have to code for the worst case scenario. – HaiXin Tie Oct 12 '13 at 15:41
  • 9
    This answer seems to be implying that you'd never need e.g. a `volatile int`. This isn't the case. Volatile is also used to establish a happens-before relationship; the atomicity of a shared non-volatile `int` only guarantees that other threads will never see a garbage value. Unless you use a `volatile int`, it is legal (if unlikely) for the other threads to never see the updated value. – Kevin Feb 21 '16 at 01:38
  • 1
    I quite agree with Kevin. In terms of visibility, which is defined in the memory model, a variable - all primitive type (including long and double) and reference - should be declared as volatile for other threads to see its updated value, regardless of atomicity. – Kewei Shang Mar 17 '16 at 19:59
11

No they are not. A 64 bit store is treated as two separate 32 bit stores. So in a concurrent environment that variable can have the high 32 of one write and the low 32 of another write, obviously not thread safe.

John Vint
  • 39,695
  • 7
  • 78
  • 108
10

Section 8.4 of the Java Virtual Machine specification states that a double or long that is not declared volatile is treated as two 32-bit variables for load, store, read and write operations.

Furthermore, the manner of encoding and the order of the two 32-bit operations is not defined.

The spec does encourage implementations to make the operation atomic but they do not require it.

Ryan Schipper
  • 1,019
  • 7
  • 8
8

If the variable is volatile, then the read/write is guaranteed atomic, but not if the variable is non-volatile.

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.

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.

JLS 17.7 - Non-atomic Treatment of double and long

When multiple threads are accessing a long value without synchronization, it is necessary to use volatile to ensure changes made by one thread are visible to other threads, and to ensure the read/write is atomic.

reevesy
  • 3,452
  • 1
  • 26
  • 23
mdma
  • 56,943
  • 12
  • 94
  • 128