I am still pretty new to the concept of threading, and try to understand more about it. Recently, I came across a blog post on What Volatile Means in Java by Jeremy Manson, where he writes:
When one thread writes to a volatile variable, and another thread sees that write, the first thread is telling the second about all of the contents of memory up until it performed the write to that volatile variable. [...] all of the memory contents seen by Thread 1, before it wrote to
[volatile] ready
, must be visible to Thread 2, after it reads the valuetrue
forready
. [emphasis added by myself]
Now, does that mean that all variables (volatile or not) held in Thread 1's memory at the time of the write to the volatile variable will become visible to Thread 2 after it reads that volatile variable? If so, is it possible to puzzle that statement together from the official Java documentation/Oracle sources? And from which version of Java onwards will this work?
In particular, if all Threads share the following class variables:
private String s = "running";
private volatile boolean b = false;
And Thread 1 executes the following first:
s = "done";
b = true;
And Thread 2 then executes afterwards (after Thread 1 wrote to the volatile field):
boolean flag = b; //read from volatile
System.out.println(s);
Would this be guaranteed to print "done"?
What would happen if instead of declaring b
as volatile
I put the write and read into a synchronized
block?
Additionally, in a discussion entitled "Are static variables shared between threads?", @TREE writes:
Don't use volatile to protect more than one piece of shared state.
Why? (Sorry; I can't comment yet on other questions, or I would have asked there...)
Yes, it is guaranteed that thread 2 will print "done" . Of course, that is if the write to b
in Thread 1 actually happens before the read from b
in Thread 2, rather than happening at the same time, or earlier!
The heart of the reasoning here is the happens-before relationship. Multithreaded program executions are seen as being made of events. Events can be related by happens-before relationships, which say that one event happens before another. Even if two events are not directly related, if you can trace a chain of happens-before relationships from one event to another, then you can say that one happens before the other.
In your case, you have the following events:
s
b
b
s
And the following rules come into play:
The following happens-before relationships therefore exist:
s
happens before Thread 1 writes to b
(program order rule)b
happens before Thread 2 reads from b
(volatile rule)b
happens before Thread 2 reads from s
(program order rule)If you follow that chain, you can see that as a result:
s
happens before Thread 2 reads from s