GeeCON Prague 2014*
The moose likes Threads and Synchronization and the fly likes Thread and variable value question? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Thread and variable value question?" Watch "Thread and variable value question?" New topic
Author

Thread and variable value question?

Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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.


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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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 ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
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
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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


Here I suspect I may need volatile?
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
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:



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
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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

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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I wish I knew, I tried to read the relevent sections in the JLS but it was over my head.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
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
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
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:



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
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Thats interesting. Ill have to read that spec. spec 1.5?
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Yes, 3rd edition.
 
GeeCON Prague 2014
 
subject: Thread and variable value question?