Experimenting with "volatile"

[Reiner Herman]

Hallo.
I am reading about the happens-before relationship in the JMM trying to understand:

"A write to a volatile field happens-before every subsequent read of that same field"

I have 2 questions.

1) According to this description, why doesnt my code below output 5 ?

  public class Test implements Runnable {
	private static volatile int id = 4;
	public void run() {
			id = -4;
	}
	public static void setId(int idNew) {
		id = idNew;
	}
	public static void main(String[] args) {
		Runnable runner = new Test();
		new Thread(runner).start();
		setId(5);
		System.out.println("Id at this time is: " + id);
	}
}
  

Output:

  Id at this time is: -4
  

2) In the description what does "subsequent refer to" ? So there is another ordering besides happens-before, how is this defined ?

[Ireneusz Kordal]

Look at this experiment, maybe you'll catch:

public class Volatile implements Runnable {

    // not marked as 'volatile', but it should be!
    static boolean flag;
    static long time = System.currentTimeMillis();

    public void run() {
        System.out.println("entering run()");

        while (!flag) {
            // busy loop
            for (int i = 1; i != 0; i++){}
        }

        long t1 = System.currentTimeMillis();

        System.out.println("leaving run()" + (t1 - time) + " ms");
    }

    public static void main(String[] args) {
        try {
            System.out.println("entering main");
            Volatile vol = new Volatile();

            Thread.sleep(100);

            Thread t = new Thread(vol);
            t.start();

            Thread.sleep(1000);

            flag = true;
            System.out.println("Setting flag = true " + (System.currentTimeMillis() - time) + " ms");

            Thread.sleep(1000);
            System.out.println("leaving main " + (System.currentTimeMillis() - time) + " ms");

        } catch (InterruptedException x) {
        }
    }
}

On my machine (linux amd 64 2 cores JVM 6) result was:

run:
entering main
entering run()
Setting flag = true 1169 ms
leaving main 2169 ms
.....
BUILD STOPPED (total time: 57 seconds)
 

I stopped program after 1 minute .... surprise - thread 't' didn't see that 'flag' had been changed and was still running !!!

When I marked 'flag' as volatile result was:

run:
entering main
entering run()
Setting flag = true 1155 ms
leaving run()1156 ms
leaving main 2155 ms
BUILD SUCCESSFUL (total time: 3 seconds)

This time "A write to a volatile field in the main thread happened-before every subsequent read of that same field in the 't' thread" ;)

On your machine you could get different results ... because threads are not predictable.
But with 'flag' declared as volatile this program will always end.

[Campbell Ritchie]

Moving thread as too difficult for "beginning."

[Campbell Ritchie]

Moved to "JiG" forum . . . and welcome to JavaRanch

[Rob Spoor]

Moving again since this is more thread related, and we have a dedicated forum for that.

[Kaustav Ganguly]

try invoking join() method on the runner thread in between line 11 and 12 , then the output should be 5.

Actually we have two threads here , the main thread and the one you are creating , now which one will be executed first is not gauranted.


So try using join as following

        Runnable runner = new Test_1();   
        Thread testThread= new Thread(runner);
        testThread.start();
        try 
       {
	testThread.join();
        } catch (InterruptedException e) 
       {
           // TODO Auto-generated catch block
           e.printStackTrace();
        }
        
        setId(5);   
        System.out.println("Id at this time is: " + id);   

[Reiner Herman]

Ireneusz Kordal wrote:
But with 'flag' declared as volatile this program will always end.

But that is what I don't understand since I do have declared the id volatile.

Kaustav Ganguly wrote:try invoking join() method on the runner thread in between line 11 and 12 , then the output should be 5.

It is not that I want the output to be 5, but that I am trying to understand what volatile does and it seems to do something from what I excpect the way I read the description of the JMM.

How about that "subsequent" thing ? When does soething subseed something else when it is not the happens-before relation that is the ordering ?

[Reiner Herman]

I tried the following wich confuses me more, inside run I printout the id before changing it and now the program seems to consistently outputs 5. By the way the first example seemed to always output -4 but at times outputs 5.

public class Test implements Runnable {
	private static volatile int id = 4;
	public void run() {
		System.out.println("Id inside run: " + id);
			id = -4;
	}
	public static void setId(int idNew) {
		id = idNew;
	}
	public static void main(String[] args) {
		Runnable runner = new Test();
		new Thread(runner).start();
		setId(5);
		System.out.println("Id at this time is: " + id);
	}
}

This seem to consistently output either:

Id at this time is: 5
Id inside run: 5

or

Id at this time is: 4
Id inside run: 5

[Reiner Herman]

I still haven't figured out what is happening. Would really like a hint from someone who knows Javas memory model "cold".

[Rok Štelcer]

Hi,

Calling a start on a newly created thread, doesn't mean that is is already running (state=runnable).
It just means that it is ready to run and it is up to the thread scheduler to decide when it will actually run/invoke it (state=running).

So in your example, the setId method is called before the thread has actually started (you could even say that you set it in a single threaded env.).

Ireneusz Kordal wrote: This time "A write to a volatile field in the main thread happened-before every subsequent read of that same field in the 't' thread" ;)

I'm not sure from where did you get the "main thread" part.
Read the following link Threads and Locks.
... second discussion after section "17.4.5 Happens-before Order"

Hope this helps.


Regards,
Rok

[Reiner Herman]

Thank you for the reply.

This is from the Java Doc on threads start method: "Causes this thread to begin execution; the Java Virtual Machine calls the run method of this thread."

So the call does not make the status of the thread "running" ?

And from 17.4.4 in the specs:

"An action that starts a thread synchronizes-with the first action in the thread it starts."

I am still confused...

Maybe I have to study the spec thoroughly.

[abhay bansal]

The new Thread().start() method calls the native start method. It is in the hands of OS when the thread will start running. In this particular example the two threads are independent when you call the start method, it might give different result each time you run it.