Thread and variable value question?

[Mr. C Lamont Gilbert]

I know how synchronization works between two concurrently running threads. In this case the order of access is not guaranteed, only the exclusivity of access. There is a case though where I start another thread to do some work for the current thread. I want to ensure the returned value is seen by the current thread. So you would think that locking is enough, but I am not so sure.

class AClass {
    Object o;
    Lock lock;
    void method(){
       synchronized(lock){
          if(o == null) {
             Runnable run = new Runnable(){
             public void run(){
                o = new Object();
             }
             Thread t = new Thread(run);
             t.start();
             t.join();
          }
       }
    }
}

Here since o=new Object() is not synchronized I don't think my initial thread has any guarantee of seeing this change. I have played around with passing in references and other stuff but the bottom line remains.


How can one thread, start another thread to do a job, and be guaranteed to see the result of that job.

Myabe I need to start the thread, and release the lock before I join. And let the 2nd thread get the lock while setting the value? But then its hard to check if o==null first.

[Stan James]

After the join() you know the Runnable is done. Can you wait that long to check the value? Also look into Future which is just for this kind of thing.

If you need to sync up on the variable before the Runnable is done things get trickier. Wait and notify come to mind, a queue might be interesting.

BTW: t.start() followed by t.join() kinda defeats the point of threads. Can we assume you really wanted to do more stuff in between these but left it out for a short example?
[ July 31, 2006: Message edited by: Stan James ]

[Ken Blair]

Originally posted by Stan James:
After the join() you know the Runnable is done. Can you wait that long to check the value? Also look into Future which is just for this kind of thing.

If you need to sync up on the variable before the Runnable is done things get trickier. Wait and notify come to mind, a queue might be interesting.

BTW: t.start() followed by t.join() kinda defeats the point of threads. Can we assume you really wanted to do more stuff in between these but left it out for a short example?

[ July 31, 2006: Message edited by: Stan James ]

I would assume start() followed by join() was purely to create an example. After join() returns the Runnable has finished execution, but does that mean that the value of o has actually been put to main memory and that the original thread can see the updated value? Can't the original thread have it's own cached variable that hasn't been changed?

[Mr. C Lamont Gilbert]

Exactly what I mean Ken. Since the call to set 'o' was not performed within a synchronized block. The example is simplified, the Runnable is created for a special reason, but its the same as what you see here.

How can I get some synchronization in there so I can be guaranteed to see the updated value? join() does not release the lock, so I can't just synch the assignment in the runnable.

The root is, Thread A needs to start and get thread B to perform some work for it. After thread B is done, Thread A needs to be able to get the results of that task. I could do something like this, but I suspect its no good either

class AClass {
    Object o;
    Lock lock;
    void method(){
 
    Runnable run = new Runnable(){
      public void run(){
        synchronized(lock){
          o = new Object();
        }
      }
    };
 
    boolean get;
    synchronized(lock){
      if(o == null) {
        get = true;
      }
    }
    if(get) {
      Thread t = new Thread(run);
      t.start();
      t.join();
    }
    synchronized(lock){
      print("o = " + o);
    }
}

Here I suspect I may need volatile?

[Ken Blair]

I don't know and the question is identical to one I was about to post. The example in which it came up for me was at another forum when discussing how to properly kill a thread. This example might serve to help demonstrate the question we both seem to have:

public final MyRunnable implements Runnable {
 
    private boolean isRunning;
 
    public void run() {
        isRunning = true;
        while (isRunning) {
            // code
        }
    }
 
    public void isRunning() {
        return isRunning;
    }
 
    public void stop() {
        isRunning = false;
    }
 
}

A simple example and the question is about the variable isRunning. Since stop() is going to be called from a thread other than the thread executing run() will the change to isRunning be seen immediately? Is it possible it may never be seen? What if we synchronize stop() but not run(), or likewise run() but not stop()? Will that have any effect or must they both be synchronized? Making isRunning volatile would solve any problem I suspect, but is that the best solution?

[Mr. C Lamont Gilbert]

Definitely that wont work for the reason you cite. I have dealt with that one though.

public final MyRunnable implements Runnable {
    private boolean isRunning=true;
    private Object lock = new Object();
 
    public void run() {
        boolean go=true;//for determinism
        while (go) {
            // code
            synchronized(lock){
              go = isRunning;
            }
        }
    }
 
    public void isRunning() {
        synchronized(lock){
            return isRunning;
        }
    }
 
    public void stop() {
        synchronized(lock){
           isRunning = false;
        }
    }
 }

This would be the proper way to handle this for the reasons you cite. Also with this technique you can easily use wait/notify.

I think my issue may be ok since join guarantees that the thread has stopped. Its hard for me to view join() as enforcing order, but I think this may work.

The former 'volatile' would not solve this one. But in 1.5 I believe it will.
[ August 01, 2006: Message edited by: Mr. C Lamont Gilbert ]

[Stan James]

Where can I read up on the issues with cached values? I've used the "while isRunning" code just as Ken showed with no problems, but maybe I just got lucky.

[Ken Blair]

I wish I knew, I tried to read the relevent sections in the JLS but it was over my head.

[Mr. C Lamont Gilbert]

Ch. 17 of the JLS, Ch. 8 of the JVM Spec, and of course, these forums

I learned through reading those two sections of the specs, arguing countless months on the forums, and I have a MSCE [Masters] with a specialization in distributed computing. I spend so much time in this forum because I learn a lot from asking and answering questions.

Some of your basic Java books do have sections on threading that seem to get the issues right. But if I recommended the Java book that taught me about Java threads everyone would laugh

[Ken Blair]

What would happen if (in my example) you synchronized one but not the other? I think it's probably the same as what would happen in your example. Even if we know that the variable has already been changed the question is whether or not the other thread sees it, if ever, and when. Or at least that's my interpretation.

[Mr. C Lamont Gilbert]

Yes, one thread is not guaranteed to see the update of the other thread to that variable. In practice it will eventually see it. In a high performance environment, it may miss it quite a few times though.

[Ken Blair]

Did you find the answer to your original question? After looking at the JLS I believe your original example will work. Specifically, after looking at 17.4.4 and this line:

The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated. T2 may accomplish this by calling T1.isAlive() or T1.join().

Therefore do they not have a synchronized-with relationship just as if the keyword synchronized had been used with the same monitor? In other words, aren't these two semantically identical:

void method() {
    synchronized (lock) {
        if (o == null) {
            Runnable runner = new Runnable() {
                public void run() {
                    o = new Object();
                }
            };
            Thread t = new Thread(runner);
            t.start();
            t.join();
        }
    }
}
 
void method() {
    synchronized (lock) {
        if (o == null) {
            Runnable runner = new Runnable() {
                public [B]synchronized[/B] void run() {
                    o = new Object();
                    notify();
                }
            };
            Thread t = new Thread(runner);
            synchronized (runner) {
                t.start();
                try {
                    runner.wait();
                } catch (InterruptedException e) {}
            }
        }
    }
}

I know it's ugly but I'm just trying to illustrate a point.
[ August 07, 2006: Message edited by: Ken Blair ]

[Mr. C Lamont Gilbert]

Thats interesting. Ill have to read that spec. spec 1.5?

[Ken Blair]

Yes, 3rd edition.