Yeah could be. but if you use WAIT() overload version then it would interrupt as time goes down. here still it would be a guess saying b would run first. you can't since it's JVM dependent. but seems like if you don't notify then MAIN would get chance to run.
wait() and notify() is used internally -- to implement the join() method. Basically, a notifyAll() is sent on the thread object, when a thread terminates, in order to wakeup all the threads waiting to join.
ThreadA is waiting(give up the lock to ThreadB) for ThreadB notify(),i.e to get object lock again.After ThreadB loop codes completion the lock will be released by ThreadB.So again threadA can get it back with out notification.
Originally posted by kathir vel: In this sample program also the same logic...with out notify waiting thread can continue execution once it get the object lock again.
According to the K&B book the program will wait forever even if the lock is released. It does mention that sometimes the thread will sometimes start on it's own even without a notify() depending on the JVM. I wonder if this is the reason.
Originally posted by Jeff Schuler: According to the K&B book the program will wait forever even if the lock is released. It does mention that sometimes the thread will sometimes start on it's own even without a notify() depending on the JVM. I wonder if this is the reason.
It's the same as with your example. The calculator thread calls notifyAll() on itself when it dies. But as you suppose, it will not work in the general case. look at the following example:Without the notify, the second thread will wait forever.
HI i have same concern .In K&B self test Answer explanation note, its written that once a thread finds wait() method it will wait forever if nobody call notify but in Khalid mughal its written that if notify() is not called for a particular period ,then waiting thread will wake up and it will not know the difference whether some one notify it or it wakes up itself....
A wop bop a lu bob a womp bam boom. Tutti frutti ad: