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.
we will call all of them inside the synchronized block
now when wait() executes the current thread under execution releases lock on q and enters in to wait set of the object q.
when some other thread obtains lock on q and executes notifyAll() it will notify all the threads in wait set of object q.
1. Now what happens when the thread wakes up will it enter runnable state or will it continue its execution from where
I think it enters runnable state as it already released the lock and cant continue from where it stopped. It should begin from scratch
2. Is there any difference in calling wait() and q.wait() ?
I think no
and when we call Thread.sleep(1000) then the current thread holds the lock and goes to blocked state and once the sleep time expires
continues from where it stopped as it already owns the lock. Is this correct?
3. is wait set used only by wait(), notify() and notifyAll() or will it be used by Sleep and any other APIs too? in other words
wait set == blocked state?
When wait() is executed on an object, the executing thread will release the object monitor and then go into a waiting state. When it wakes up again, through a call to notify() or notifyAll() on the object it is waiting on by another thread, it enters blocking state. Blocking state is the state where it has to reacquire the object monitor. The thread will continue where it was when the wait() method was called, but it first blocks until the synchronized block it's in is free (there is no other thread holding the object monitor). After it has reacquired the lock, it will go to runnable state and continue where it left.
Yes, there is a difference between wait() and q.wait(). wait() is the same as this.wait(). If q is not the same as 'this', then the thread will wait on a different object.
When you call Thread.sleep(), if the current thread holds the lock it will not release it. It simply goes to waiting mode, after the specified amount of time is passed, and it will just continue to run without having to reacquire the lock.
What do you mean by wait set?
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Yeah, this is no different from what I said, I just didn't explicitly mention the word 'runnable'
Chandra shekar M
Joined: Dec 20, 2006
Thanks for the replies,
Yeah the object which invokes wait() and counterparts should have a lock on that object;
otherwise it will throw illegalMonitorstateException.
Now i have a question. In the Java docs it is said that when we invoke wait the thread will be in the wait set of that object and when
notify is called on the same object it will notify the threads in the waitset of that object; Which then comes to runnable state and then
re acquires the lock and continues from where it stopped.
Q1.so does that mean when we call wait, sleep or any other API through which we block the thread; It well be moved to wait set which corresponds to
blocked state of thread or only in case of wait?
below is the code i have written.
The out put i get is always
before write wait 3
Main Thread Ended
after writeData returning from wait0
Write thread looks ok to me . Can any body comment on read operation.
Q2.if we observe the read operation the list had [0,1,2] when reading it is printing 0 2 and then 1. Also note that both read threads t1 and t2 have
entered the synchronization block both are raising readData notify how can two thread enter the same synchronized block. I think there is some thing
i am missing?
after the specified amount of time is passed, and it will just continue to run
Hello Stephan...If havent forgotten what I studied about 'sleeping threads', when they wake up, they go to the 'runnable state' subjected to when the scheduler considers the thread oportuned to run.
Please excuse me if I am wrong, I recently woke up from sleep.
Stephan van Hulst wrote:Yeah, this is no different from what I said, I just didn't explicitly mention the word 'runnable'
I think that Jacob was specifically talking about, is that when a thread comes back from Thread.sleep(), then it will not start running immediately, but rather goes into the "runnable pool", waiting for its turn before it actually continues to run.
I'm sure this was what you meant too Stephan, just trying to be clear on the differences as they can easily be mixed up.
Chandra, this wait set you refer to is indeed just the set of threads that are waiting to reacquire the lock on the object monitor. So they are not in waiting state, but in blocking state. Blocking mode is applicable to threads that have called the wait() methods, or are about to enter a synchronized block or method.
Yes, if a thread is in the wait set, that implies it's in the blocked state.
Is everything clear to you now?
Chandra shekar M
Joined: Dec 20, 2006
I found the answers in the JLS and in this Thread
Actually wait, notify, notifyAll are all in the object Class; every object will have Wait set and lock. Wait set is used only by wait, notify and notifyAll methods only.
BlockedState is a generalized word used for wait set, sleeping and suspended threads. As suggested by Kathy siera its ok to use Blocked state/Blocked thread and no need to worry about the finer states with in blocked state. For finer states wait, notify, notifyAll will be in wait set (as in JLS) and sleep, yield, join not sure will be part of blocked state.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Clarification in wait, notify and notifyAll methods