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?
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.
Joined: Jan 03, 2005
thats ok. i too know that problem exists. it can be avoided by
so that the main thread will not call wait() unnecessarily.
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>
Joined: May 26, 2006
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.