I have the similar doubt regarding wait() and notify(). the scenario is somewhat like this " when one thread A is executing synchronized method and done with it, eventually it notifies with notifyall(). while the main thread which want to use the result of that thread A, then why we need to invoke wait() method on thread A instead the main thread is waiting ",
-i don't get it correctly, ,may its because when wait() is encountered by the instance of thread A it will release the lock., if so then thread A should release the all when it hits the notifyall()in sync code.
- please correct me if i am wrong somewhere. - thank you
I hope that I understand the issue correctly but here is the impression I get reading it.
The way to think of these things is that the issue of wait and notify is not simply about scheduling and the scheduling priorities ( it is NOT so much about WHO should be executing) but rather that there is some resource or structure that must be accessed exclusively, ONE thread at a time.
The idea of the synchronized method is that the API maintains/manages the "single thread access" to the method itself. Where a problem shows up is, once you get in there, if you find that you are missing some other resource that you need, wait() gives you a way to voluntarily release the locks and suspend the "owning" thread WHILE placing itself on a queue to await re-dispatching later WITH the LOCK already re-established. This helps to prevent threads from hanging on to locks for extended periods. So NOW we have a way that we can voluntarily say "let me give up the lock for now BUT put me back in later to re-try for my missing/unavailable resource.
SO now the JVM can dispatch another thread that may be waiting on the synchronized method. (the underlying idea here is that, somewhere in the application, whatever held the resource that was unavailable will relinquish it and call notify() or notifyAll(). This will tell the JVM "I am through with a protected resource so go dispatch a thread that may have been waiting on it".
The whole idea is that only ONE thread of execution has access to the resources at once, others have to wait, even if the priorities are upside down because the aim is to protect the integrity of the resource or structure. Now, if a higher priority thread is in wait,and a lower priority thread calls notifyAll(), I'd be willing to bet the higher priority thread will be dispatched pretty soon.
SCJP - 86% - June 11, 2009
And, just as an afterthought, when you call wait() and are suspended you will eventually(thanks to someone's notify() call) be redispatched at the line following the wait with the synchronization lock for the method BACK IN PLACE.
BUT, depending on the logic that controls the resources, the rest of the resourcs might STILL not be ready yet, depending on how many resources are in question and how many threads are attempting to secure them. So, when you resume after a wait() it pays to re-check the resources you need.
SCJP - 86% - June 11, 2009
If tomatoes are a fruit, then ketchup must be a jam. Taste this tiny ad: