13

I am quoting from Oracle's Java documentation on Atomic Access

  • Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
  • Reads and writes are atomic for all variables declared volatile (including long and double variables).

I understand how volatile works. But mentioning the requirement to declare volatile explicitly for long and double variables to get atomic access in the second statement, is making volatile declaration for reference variables and for most primitive variables (all types except long and double) in the first statement optional.

But I am seeing codes which use explicit volatile declaration in int primitive type to achieve atomic access; and not doing so not guaranteeing atomic access.

int variable1;          // no atomic access
volatile int variable2; // atomic access

Am I missing something?

Mark Stewart
  • 2,046
  • 4
  • 22
  • 32
Alanpatchi
  • 1,177
  • 10
  • 20
  • 2
    [Atomicity is very different to volatility...](https://stackoverflow.com/questions/1006655/are-java-primitive-ints-atomic-by-design-or-by-accident#answer-1006712) `volatile` keyword in the last line is used for a visibility purpose (not for atomicity). – Oleksandr Pyrohov May 16 '18 at 15:30
  • 2
    @Oleksandr that link definitely helped. But I was actually mixing up atomicity and visibility which I got cleared up from the answers. – Alanpatchi May 16 '18 at 15:47

2 Answers2

11

The first statement does not refer to making reference variables and primitive variables (except long and double) volatile.

It says reads and writes of all reference variables and all primitives except long and double are atomic (by default). To make reads and writes of long and double atomic they need to be volatile.

Atomicity does not have anything to do with visibility.

The following paragraph on the same doc

Atomic actions cannot be interleaved, so they can be used without fear of thread interference. However, this does not eliminate all need to synchronize atomic actions, because memory consistency errors are still possible. Using volatile variables reduces the risk of memory consistency errors, because any write to a volatile variable establishes a happens-before relationship with subsequent reads of that same variable.

So, statements like a = 1 where a is an int (for example) are atomic but you still need to have volatile if you want the assignment to be visible for any subsequent reading threads.

Reading/Writing to a long/double variable is a compound action and making it volatile ensures that it is atomic.

Thiyagu
  • 17,362
  • 5
  • 42
  • 79
6

The volatile keyword does more than guarantee atomic access, it also comes with visibility guarantees.

As double and long primitives take twice the space of an int (64 bits) updating their values can happen in two 32 bit chunks. As such, without volatile, you could see the value of the long or double in between those two steps. This is not the case for other primitive variables.

But atomic access is not the same as visibility. The volatile keyword also guarantees that all reads of the variable on other threads that happen after a write to it, will see the new value. So that's why the use of volatile on other primitive types can still be needed.

When a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations. Volatile variables are not cached in registers or in caches where they are hidden from other processors, so a read of a volatile variable always returns the most recent write by any thread.

Java Concurrency in Practice : 3.1.4 Volatile variables

bowmore
  • 10,842
  • 1
  • 35
  • 43