• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Thread and variable value question?

 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thats interesting. Ill have to read that spec. spec 1.5?
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, 3rd edition.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic