This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Does notify() and notifyAll() have any effect on a thread that's sleeping(Thread.sleep())? What are *all possible ways* that cause a thread to come out of its sleeping state? Though these questions seem very basic, please don't mind answering them - I've got some issues understanding them. Thanks in adv!
Did you see the behavior of your code by removing synch from the run method of the SleepingThread class.
As I know, if the sleep() method is called from the sync block, sleep() does not release the lock, at least until it wakes up and it is also not guaranteed that after waking it will immediately release the lock.
I think there is nothing to do with sleep(...); it is all about the sync block, no two threads can acquire the same sync block together is the known fact; if the thread, in which sleep(...) is executing, is acquiring the lock, how can notify be executed on the same object block.
Thread expert Henry Wong, is not available for so long. He could help us to get the things clearly...
Anyways, Megha, your code gives some idea to me! (Thanks for that)
Herz the link to image: http://www.bpurcell.org/blog/images/934/threads2.gif If you right-click the image and select its properties you can see the link. This info could help you at JavaRanch in getting the links to images that are posted in the forums. Well, herz the link to the page that hosts the above image: http://www.bpurcell.org/blog/index.cfm?mode=entry&ENTRY=934 I think therz something wrong in the image. Itz not correct that a sleeping thread can be waken up by notify() etc. Usually, threads sleep to give another threads of same priority a chance to execute. Whereas, threads use notify() and notifyAll() in inter-thread interaction. The threads that are sleeping MUST sleep for the amount of time specified. In case some one disturbs them it would be an "interruption" and immediately the sleeping threads throw an exception(checked) while coming out of the sleep. And if none has disturbed their sleep, they will certainly wake up after the prescribed duration of sleep is finished. In which case, they move to runnable state and not running state. That's all about Thread.sleep(). Coming to notify(), its used to communicate/send message to the thread that's waiting for some object's lock. Because itz essential. Usually such inter thread communication takes place only in case of object lock. The thread that intentionally gives up its lock only to get it later uses wait() to do such. After invoking wait() it simply goes into Object's lock waiting pool(treat this as a separate state). Upon notified about the lock it still remains in the object's lock pool because some another thread might have also got the lock! Well, after getting the required lock, it moves into runnbale state where it still has to wait for the thread scedulers' mercy to get selected to run/execute. So, the conclusion is, notify() has nothing to do with sleep(). If you need a proof, write some code and check it yourself. [ April 28, 2007: Message edited by: Faisal Pasha ]