It is an advocated paradigm that wait() should be invoked inside a while loop inside a synchronized block.
My question is how does the waiting() thread get the lock back ?
// Thread 1
synchronized (mon) {
while (!condition)
mon.wait();
// Do something
}
//Thread 2
synchronized (mon) {//set condition appropriately
mon.notify();
}
Consider the thread 1 runs first and starts waiting for the condition. It releases the lock and the thread 2 obtains the lock sets the condition and notifies thread 1. Now thread 1 gets the lock, checks the condition and starts executing "do something".
My question is when Thread 1 is notified it starts execution from the while condition, the line of code which had Synchronized(mon) is never executed again then how does thread 1 acquire the lock ? What are the internal dynamics that give the lock back to Thread 1 ?
So, when wait() method is called by a thread, then it gives up the lock on that resource and goes to sleep until some other thread enters the same monitor and invokes the notify() or notifyAll() method.
The wait() Method Simply put, calling wait() forces the current thread to wait until some other thread invokes notify() or notifyAll() on the same object. For this, the current thread must own the object's monitor.
Yes and no. All the waiting threads will wake up, but they still have to reacquire the object lock. So the threads will not run in parallel: they must each wait for the object lock to be freed. Thus only one thread can run at a time, and only after the thread that called the notifyAll() method releases its lock.
The newCondition() methodwait() will atomically release the lock before the wait and re-acquire the lock before the wait returns. Syntax: public Condition newCondition()
When Thread1 is notified the thread has to acquire the lock before it can exit the wait method, see the java doc for Object#wait:
The thread
T
is then removed from the wait set for this object and re-enabled for thread scheduling. It then competes in the usual manner with other threads for the right to synchronize on the object; once it has gained control of the object, all its synchronization claims on the object are restored to the status quo ante - that is, to the situation as of the time that thewait
method was invoked. ThreadT
then returns from the invocation of thewait
method. Thus, on return from thewait
method, the synchronization state of the object and of threadT
is exactly as it was when thewait
method was invoked.
synchronized(mon)
is not an expression that has to be executed.
It's a syntax element in the source code that tells the compiler (and then the runtime) that the wrapped section of the code must only be executed after the lock associated with mon
has been acquired by the current thread, even if you don't "come from" the line of code before the synchronized block.
wait()
releases the lock, and must reacquire it before returning.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With