The "Volatile" Puzzle

Question

Need a simple example code that works differently with and without "volatile".
I understand the need for 'volatile' keyword and what it does in java. However, I also vaguely remember reading that this is no longer necessary. i.e., the compiler and jvm of these days takes care of local caching and memory writes very smartly. I tried several examples to see if I can reproduce a case where existence of 'volatile' really makes a difference. But, all my attempts went in vain.
Here is an example:
package volatilekw;
public class Thread1 extends Thread{
volatile int answer = 0;
public void setAnswer(int i) {
answer = i;
@Override
public void run() {
for (int i=0;i<100;i++) {
System.out.print(answer);
try {
sleep(10);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
package volatilekw;
public class Thread2 extends Thread{
private Thread1 t = null;
public Thread2(Thread1 t) {
this.t = t;
@Override
public void run() {
for (int i=0;i<100;i++) {
try {
sleep(10);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
if (i == 1)
t.setAnswer(1);
package volatilekw;
public class Gotgo {
public static void main(String[] args) {
Thread1 t1 = new Thread1();
Thread2 t2 = new Thread2(t1);
t1.start();
t2.start();
Irrespective of whether the "answer" is volatile or not, the output is same with JDK 1.6. I ran several times and even tried decrementing sleep value. If my understanding goes right, the writes of thread2 on answer might not be visible to thread t1 until it caches it. But, this is never the case.
Is there a good example that demonstrate that 'volatile' does make a difference? I am looking for a piece of code when run with and without 'volatile' gives two different outputs.

Answer 1

853929 wrote:
Need a simple example code that works differently with and without "volatile".Impossible to produce reliably. Without volatile, some things can happen, depending on timing, the OS's scheduler, the underlying hardware, other processes running, the JVM implementation, etc., but there's no guarantee that those things ever will happen. However, it's generally bad if they do, so volatile is one way of ensuring that they don't.
I understand the need for 'volatile' keyword and what it does in java. However, I also vaguely remember reading that this is no longer necessary. i.e., the compiler and jvm of these days takes care of local caching and memory writes very smartly.Nope. The use-case for volatile is still there.
Volatile was never strictly necessary. We've always been able to accomplish what volatile does by syncing every access to the variable in question. However, when all you need is that all threads see the same copy, and you don't have other atomicity issues to deal with, volatile can save some runtime overhead relative to syncing, and, more importantly, it can make for less cluttered code.
I tried several examples to see if I can reproduce a case where existence of 'volatile' really makes a difference. But, all my attempts went in vain.Try a multi-cpu box, with not much else happening on it, create as many threads as there are CPUs, and have all threads run a loop from 0 to 10,000 or 100,000,00 or millions that does nothing more than x++ on some shared member variable.
With volatile, and N threads and a count up to M, you'll see a final value of N x M.
Without volatile, you might see a value less than N x M.