Quantcast
Channel: Understanding Java volatile visibility - Stack Overflow
Viewing all articles
Browse latest Browse all 6

Understanding Java volatile visibility

$
0
0

I'm reading about the Java volatile keyword and have confusion about its 'visibility'.

A typical usage of volatile keyword is:

volatile boolean ready = false;int value = 0;void publisher() {    value = 5;    ready = true;}void subscriber() {    while (!ready) {}    System.out.println(value);}

As explained by most tutorials, using volatile for ready makes sure that:

  • change to ready on publisher thread is immediately visible to other threads (subscriber);
  • when ready's change is visible to other thread, any variable update preceding to ready (here is value's change) is also visible to other threads;

I understand the 2nd, because volatile variable prevents memory reordering by using memory barriers, so writes before volatile write cannot be reordered after it, and reads after volatile read cannot be reordered before it. This is how ready prevents printing value = 0 in the above demo.

But I have confusion about the 1st guarantee, which is visibility of the volatile variable itself. That sounds a very vague definition to me.

In other words, my confusion is just on SINGLE variable's visibility, not multiple variables' reordering or something. Let's simplify the above example:

volatile boolean ready = false;void publisher() {    ready = true;}void subscriber() {    while (!ready) {}}

If ready is not defined volatile, is it possible that subscriber get stuck infinitely in the while loop? Why?

A few questions I want to ask:

  • What does 'immediately visible' mean? Write operation takes some time, so after how long can other threads see volatile's change? Can a read in another thread that happens very shortly after the write starts but before the write finishes see the change?
  • Visibility, for modern CPUs is guaranteed by cache coherence protocol (e.g. MESI) anyway, then why do we need volatile here?
  • Some articles say volatile variable uses memory directly instead of CPU cache, which guarantees visibility between threads. That doesn't sound a correct explain.
   Time : ----------------------------------------------------------> writer : --------- | write | -----------------------reader1 : ------------- | read | -------------------- can I see the change?reader2 : --------------------| read | -------------- can I see the change?

Hope I explained my question clearly.


Viewing all articles
Browse latest Browse all 6

Latest Images

Trending Articles





Latest Images