Hi, When u have to use wait and notify for synchronization, do u have to use the Thread constructor with targetobject as parameter, or will the default constructor of thread object suffice ??? Regards Shastri
I don't think these two are dependent on each other. You use the wait() and notify() method on any object that is synchronized if you want to, but the constructor for the Thread class is dependent on whether you subclass Thread or implement Runnable. I am pretty new at this, so correct me if I am wrong. If you subclass Thread, then you can use the default constructor because it will use this when it calls the run method. But when you implement Runnable then you need to pass in the object when you create the thread so it knows which run() method to call. Again, I just started learning about threads so I would be interested in other comments. Thanks, Bill
You're right, Bill -- wait and notify don't care how the threads were constructed. The Object that you are calling wait() and notify() on is like ...well, to use a JavaRanch appropriate context, it's like a corral, and the threads are like cows. When you call wait() on a object, the current cow (thread) gets locked in that corral. When you call notify() on that same corral/object later, one cow/thread is let out. Calling notifyAll() basically opens the gate -- all of the cows can get out one at a time, as soon they get a chance. Yeeeee haw! This sounds like it could be a campfire story...
Originally posted by poorna k: I have a few doubts about this example you have given. As per my understanding , wait() and notify() methods are available to all objects,and is meaningfully used when you are synchronizing an object. The wait() method defined for the object being synchronized will act on the current thread,and cause it to release its lock on the object. The notify() method on the other hand,causes the threads in the waiting pool to get notified about the imminent release of the object lock held by the current thread. Rob, as per the above understanding I feel that the corral is similar to a waiting pool for the threads(cows here ) to get a lock of the object(the gate to exit the corral). When a cow is currently in the process of exiting the gate(that is it holds lock on the object),if it executes the wait() method defined there,the current thread /cow releases the lock and comes back into the corral,giving up the gate. If on the other hand a cow /thread is on the way out,and is going to release the lock (no longer using the gate ),the notify() or notifyAll() method is called on the cows still within the corral,and the thread scheduler / ranch hand selects a cow to go out the gate.So this lucky cow gets the key to the gate. Is this correct?? thanks poorna
Rob; I really like the cow analogy. Give us more. jply
Joined: Oct 18, 2000
Poorna - It's tough to relate everything to cows, I suppose... but what you're saying seems to be mostly correct. I just want to clarify something regarding the last bit:
If on the other hand a cow /thread is on the way out,and is going to release the lock (no longer using the gate), the notify() or notifyAll() method is called on the cows still within the corral,and the thread scheduler / ranch hand selects a cow to go out the gate.So this lucky cow gets the key to the gate.
Make sure you keep in mind that notify() and notifyAll() are never *automatically* called, and if neither method was actually called, those waiting cows aren't going anywhere -- even though the gate (the object lock) is available. If you call notify() on the object, it's like you told the ranch hand to pick one cow, and let it out as soon as the gate is clear. Calling notifyAll() tells the ranch hand to let all of the cows out, one at a time, as the gate is clear. I hope the cow analogy isn't getting in the way here... in real terms, learning about the different thread states will help you understanding this stuff. It is complicated, but worth it.