When does a reference need to be atomic?

Question

What does it mean for a reference to be assigned atomically in Java?

• I do understand what it means for a long and double, that is: a thread can see partially constructed number,
• but for an object I don't understand since assignment does not mean copy just pointing to an address in memory

So what could have been wrong if reference assignment was not atomic in Java?

Answer 1

This means that you will not get the corrupted reference ever. Suppose that you have the following class:

class MyClass {
    Object obj = null;
}

In memory obj is a null pointer, usually it's an integer number like 0x00000000. Then suppose that in one thread you have an assignment:

this.obj = new Object();

Suppose that new Object() is allocated in the memory and has the pointer like 0x12345678. The reference atomicity ensures that when you check the obj from another thread you will either have a null pointer (0x00000000) or pointer to the new object (0x12345678). But under no circumstances you can get the partially assigned reference (like 0x12340000) which points to nowhere.

This might look obvious, but such problem may appear in low-level languages like C depending on the CPU architecture and memory alignment. For example if your pointer is misaligned and crosses the cache line, it's possible that it will not be synchronously updated. In order to avoid such situation Java virtual machine always aligns pointers, so they never cross the cache line.

So were the Java references non-atomic, there would be a chance when dereferencing the reference written from another thread that you get not the object which was referenced before or after the assignment, but random memory location (which may lead to segmentation fault, corrupted heap or any other disaster).