 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005Diffrence Between Notify & NotifyAll ?
Hello group, I know that its a very lame question to ask experts like you but still i cannot help myself asking the question that "What is the Diffrence Between Notify & NotifyAll" method in the Object Class. Well so far my search on the Internet and JDK Documentation reveals that 'notify' method wakes up a single thread waiting on the object and passes the control of the monitor to it. So far so good and for 'NotifyAll' it says that its will wake up all the threads waiting on the object and will select a thread to pass control to it. Well as per me during that period the unselected thread will again go back to sleep in the JVM scheduler list and they will need yet another call to Notifty (or NotifyAll) in order to wake them up. So, as far as i see there is no diffrence between notify & notifyall as they both will result in waking up a single thread waiting on the Object. If above assertions are indeed true than why to have two diffrent methods. Thanks, VJ I think you answer your own question. notifyAll wakes up a larger candidate pool of threads - any of those threads that are notified are candidates to enter the 'running' state. notify wakes up only one thread, and this thread is the only candidate to enter the 'running' state. If you have more than one thread waiting on a monitor, it almost always makes sense to use 'notifyAll.' -Fred >>notifyAll wakes up a larger candidate pool of threads - any of those >>threads that are notified are candidates to enter the 'running' state. but only one thread can ever be active inside a synchronized block right. And then to only one thread will be selected tobe woken up and all other threads though waked up will be again put to sleep. So the question remains whats the diffrence. -vj > >>notifyAll wakes up a larger candidate pool of threads - any of those > >>threads that are notified are candidates to enter the 'running' state. [quoted text clipped - 3 lines] > though waked up will be > again put to sleep. So the question remains whats the diffrence. The difference comes after that first thread leaves the synchronized block. If you've used notify, the remaining threads are still waiting, so they won't do anything until the next call to notify or notifyAll. If you've used notifyAll, then those threads are only blocked attempting to gain the lock. As soon as the first thread leaves the synchronized block, the next thread is capable of proceeeding without a second call to notify(All). And then the third thread, and the fourth, and so on. In practice, Object.wait should only be called within a loop inside of the synchronized block, so those threads will check the predicate condition again and possibly go back into the wait state. For that reason, notify() can be seen as an optimization of notifyAll(), which can only be used with there's a need for only one thread to proceed. If you call notifyAll when only one thread is needed, and assuming you've properly written a predicate loop, the remaining threads will wake up, but will then just check the predicate condition and find that the first thread made it true again, so they'll go back to waiting. Nevertheless, they do wake up and run some code.  Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>>>notifyAll wakes up a larger candidate pool of threads - any of those >>>>threads that are notified are candidates to enter the 'running' state. notifyAll causes at most one Thread to move from Thread.State.WAITING to RUNNABLE (but not immediately, see below). The other waiters will move to BLOCKED. It is possible that the thread that acquires the lock and becomes runnable was actually blocked at the start of a synchronize block, rather than waiting in wait. >>but only one thread can ever be active inside a synchronized block >>right. And then to [quoted text clipped - 9 lines] > block, the next thread is capable of proceeeding without a second call > to notify(All). And then the third thread, and the fourth, and so on. One subtlety I think worth pointing out is that wait releases the lock (however many times), waits, and then reacquires the lock. notify and notifyAll are different in that they do not release the lock. You can put the notify at the top of the synchronize block. Indeed doing so allows better exception behaviour. Also note that threads can wake spuriously. So, notify could theoretically wake more than one thread. And make sure you have that while loop - I have found shipping, commercial software that did not. > In practice, Object.wait should only be called within a loop inside of > the synchronized block, so those threads will check the predicate [quoted text clipped - 6 lines] > thread made it true again, so they'll go back to waiting. Nevertheless, > they do wake up and run some code. notify instead of notifyAll can give a huge performance improvement. I have found shipping, commercial software waking an entire waiting thread-pool of around three hundred threads for each work request. On the basis of saying what you mean, I prefer notify to notifyAll where it is applicable. You mean wake one thread, say wake one thread. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > notify instead of notifyAll can give a huge performance improvement. I > have found shipping, commercial software waking an entire waiting > thread-pool of around three hundred threads for each work request. > > On the basis of saying what you mean, I prefer notify to notifyAll where > it is applicable. You mean wake one thread, say wake one thread. But using notify() is a good deal harder to get right. Tracking /which/ thread needs to be notified is tricky what with race-conditions etc. I would recommend /against/ using notify() unless (as we always say) there is an actual, measurable, performance problem which has to be fixed. This is more than just the usual dislike of premature optimisation, since we are not just talking about the risk of wasting time on needless complexity, but the very real risk of writing code that will fail mysteriously and irreproducibly. /You/ may trust youself to get it right -- I don't suggest you shouldn't -- but I would worry if I saw notify() used in most code-bases. Anyway, with luck we shall soon all be able to forget that wait()/notify()/notifyAll() ever existed, and leave the hard work to Doug Lea and java.util.concurrency.* -- chris > But using notify() is a good deal harder to get right. Tracking /which/ thread > needs to be notified is tricky what with race-conditions etc. In fact, clearly it is ALWAYS a bug to use notify() whenever there could be heterogenous threads waiting on a single monitor. Why? Because you can't specify which thread to notify; so if you care (that is, if the threads do different things) then you've done something wrong. > Anyway, with luck we shall soon all be able to forget that > wait()/notify()/notifyAll() ever existed, and leave the hard work to Doug Lea > and java.util.concurrency.* I'm rather skeptical about this. The new package certainly introduces tools for solving a few specific common concurrency problems, such as thread pools and the classic producer/consumer example. However, if I'm writing concurrent algorithms for matrix operations in a mathematical computing library, I don't think Doug's done much to help me out. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation [me:] > > But using notify() is a good deal harder to get right. Tracking > > /which/ thread needs to be notified is tricky what with race-conditions [quoted text clipped - 4 lines] > can't specify which thread to notify; so if you care (that is, if the > threads do different things) then you've done something wrong. This doesn't seem to make sense; am I missing your point, or did you mean notifyAll() can't be used in such a situation ? > > Anyway, with luck we shall soon all be able to forget that > > wait()/notify()/notifyAll() ever existed, and leave the hard work to [quoted text clipped - 5 lines] > writing concurrent algorithms for matrix operations in a mathematical > computing library, I don't think Doug's done much to help me out. Point taken. But I don't think that concurrent matrix operations are a primary use-case for less-than-highly skilled programmers. Come to that, I don't immediately see a lot of need for complex wait-dances in such cases either, not more than can be handled by the handshake primitives (Barrier, Latch, Semaphore) that are in there already. But then, I have never paid much attention to concurrent [array] algorithms, nor really used j.u.c.* yet, so I may be missing much. BTW, do you do a lot of concurrent number crunching at DesignACourse ? ;-) -- chris >One subtlety I think worth pointing out is that wait releases the lock >(however many times), waits, and then reacquires the lock. notify and >notifyAll are different in that they do not release the lock. You can >put the notify at the top of the synchronize block. Indeed doing so >allows better exception behaviour. >Also note that threads can wake spuriously. So, notify could >theoretically wake more than one thread. And make sure you have that >while loop - I have found shipping, commercial software that did not. can you please make you point more clear by giving us a sample code listing. Thanks, ---VJ > can you please make you point more clear by giving us a sample code > listing. Which statement of Thomas's did you want sample code for? Since they're statements about multithreading and its inherently nondeterministic nature, it would be tough to demonstrate either one with sample code. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Which statement of Thomas's did you want sample code for? Since they're > statements about multithreading and its inherently nondeterministic > nature, it would be tough to demonstrate either one with sample code. Thomas suggested that the wait() call must be encapsulated in a loop that checks for wakeup conditions. I am requesting a sample that shows its usage over wait() thats not called from a loop. SignatureVJ > One subtlety I think worth pointing out is that wait releases the lock > (however many times), waits, and then reacquires the lock. notify and > notifyAll are different in that they do not release the lock. Neither notify nor notifyAll releases the lock, so I don't see how this is a difference. Indeed, if either one did release the monitor, it would be terribly broken behavior. > Also note that threads can wake spuriously. So, notify could > theoretically wake more than one thread. Indeed. Good point; the intent is for notify to wake only one thread, but it could wake more. This is consistent with seeing notify as an optimization of notifyAll, as mentioned earlier in the thread. If it's too expensive to prevent notify from acting just like notifyAll, then an implementation could do so and be entirely legal. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >>One subtlety I think worth pointing out is that wait releases the lock >>(however many times), waits, and then reacquires the lock. notify and >>notifyAll are different in that they do not release the lock. > > Neither notify nor notifyAll releases the lock, so I don't see how this > is a difference. [...] I believe Tom meant that there was a difference between wait() on the one hand and notify() / notifyAll() on the other. At least, that's the way I read it. SignatureJohn Bollinger jobollin@indiana.edu Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.