permaculture playing cards*
The moose likes Threads and Synchronization and the fly likes will wait and notify work in this scenario? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "will wait and notify work in this scenario?" Watch "will wait and notify work in this scenario?" New topic
Author

will wait and notify work in this scenario?

Ajay Xavier
Ranch Hand

Joined: Jan 03, 2005
Posts: 109
hi,

Consider the following code



Initially Thread1 gets started mthd1() gets called in which check() returns true for the first time so Thread2 gets started and Thread1 gets into wait mode (syncronized on Thread1 object). At the end of thread2() mthd1() is again called which returns false this time so notify() gets executed. will it get Thread1 out of wait mode?

my doubt is both wait and notify are issued on the same class (to be more accurate this.wait() and this.notify()). will it work in this scenario?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

my doubt is both wait and notify are issued on the same class (to be more accurate this.wait() and this.notify()). will it work in this scenario?


For wait() and notify() to work, the different threads must use the same instance to perform notifications with.

So yes, (besides a race condition), it should work, since both threads are using the same instance.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ajay Xavier
Ranch Hand

Joined: Jan 03, 2005
Posts: 109
So yes, (besides a race condition), it should work, since both threads are using the same instance.


what is the race condition yor are discussing about?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

Originally posted by Ajay Xavier:

what is the race condition yor are discussing about?


As incredibly unlikely as it is, it is theoretically possible for the new thread to start, finish the task, and send the notification, before the main thread calls the wait() method.

You should (1) setup some sort of "done" flag, which is set just prior to sending the notification, and (2) check the flag, before actually waiting. And of course, the setting and checking of the flag should be done within the synchronized blocks.

Henry
Ajay Xavier
Ranch Hand

Joined: Jan 03, 2005
Posts: 109
thats ok. i too know that problem exists. it can be avoided by

so that the main thread will not call wait() unnecessarily.
Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103
Ajay,

That looks like it won't even compile. First of all your assuming Runnable works like Thread but it doesn't. so this code:
would not compile because Thread2 doesn't implement a start method. Even if it did implement start() that would not create a new thread in the JVM. Normally when people inquire about wait() and notify() and threads they're looking for a way to have one thread "notify" another "waiting" thread of it's completion status. There are very simple and straight foward way to do that without using wait() and notify(). Here's an example:


As you see there really is no point in that example to wait since the current thread could directly do the work in MyRunnable.run(). The example is for illustrative purposes to show how to properly wait for a thread to finish. It's more likely that you would have a bunch of threads that you would wait on in which case it makes much more sense. See below:

What I'm saying is you should explain, in general, what you're trying to accomplish and maybe the answer will come more naturally.


Holla at me...<br /><a href="http://codeforfun.wordpress.com" target="_blank" rel="nofollow">http://codeforfun.wordpress.com</a>
Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103
There are other more complicated scenarios with threads that you may be tempted to use wait() notify() in. These too can be addressed with more simplistic semantics. Consider a work queue where one thread (the main thread or whatever) is farming out work for another thread (or group of threads) that wait for work and complete it as it comes in. Here's an ad-hoc example of Hell's Kitchen which kinda illustrates how threads should be managed externally without using wait/notify:


It The restaraunt would never stop once it's opened here. I'll leave it as an exercise to the reader how to gracefully stop all employees. The main idea here is you have to groups of threads that must cooperate to run the restaraunt. Waiters clear and set the tables while dishwashers take care of dirty dishes. (I'm not quite sure but you might want to wrap the dish pop() method calls in a synchronized method because I'm not sure if Stack is thread safe.) Each worker implements a polling algorithm to check for work. In a more complicated system the waiter probably could call notify on the dishwashers. For the most part they should cooperate effectively.
 
GeeCON Prague 2014
 
subject: will wait and notify work in this scenario?