0

I am trying to make sense of the reason why notify() method needs to be called for wait() to resume. Lets take the following pseudo code sample from the producer consumer problem-:

Producer pseudo-code

synchronized(data_structure) {
if(data_structure.isFull()) {
  data_structure.wait();
  }
produce(data_structure);
notify(); // The consumer thread is only notified, it cannot start execution since it does not have a lock.
    }// Only when the producer gives up the lock can the consumer start.

Consumer Pseudo Code

synchronized(data_structure) {
    if(data_structure.isEmpty()) {
      data_structure.wait();
      }
consume(data_structure);
notify(); // The Producer thread does not resume execution from this point, its just notified it can.

}//The producer thread only resumes execution when the consumer thread releases the lock. So what was the point of notify() ?

So my point is that notify() only notifies the waiting thread, nothing actually happens until the thread calling notify() releases the lock on that object. So if the waiting thread just keeps waiting and without calling notify() the lock is released and the waiting thread resumes execution, what would be the harm in that ?

I understand that notify() needs to be in a synchronized block since to avoid race conditions, but why call in the first place, if nothing happens until the lock is released ?

Its like I have a phone that I am using and another person is waiting for the phone, his only job is waiting for the phone. So when I finish my work and relinquish control of the phone he will obviously know that it is now available, why do I need to tell him its available and then relinquish control ?

By the way, as per my knowledge notifyAll() gives non-deterministic behavior if there are multiple threads waiting ? Correct me if I am wrong.

Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
ng.newbie
  • 2,807
  • 3
  • 23
  • 57
  • 6
    The waiting thread isn't waiting on the lock, it's waiting on the `notify`. – Sotirios Delimanolis Jun 29 '17 at 18:09
  • @SotiriosDelimanolis Its waiting for the lock, right ? If it waits for the lock then why is `notify()` required ? And how is this question a duplicate of the question linked ? – ng.newbie Jun 29 '17 at 18:12
  • 1
    It's not waiting for the lock, it's waiting for the `notify`. The acquisition of the lock is just a side requirement so it can proceed. – Sotirios Delimanolis Jun 29 '17 at 18:14
  • The accepted answer in the duplicate answers your confusion: _Using .wait() makes the current thread stop until another thread calls .notify() on the object it waits on. This is an addition to synchronized, which just ensures that only one thread will enter a block/method._ – Sotirios Delimanolis Jun 29 '17 at 18:14
  • @SotiriosDelimanolis And if it is waiting on `notify()` then why doesn't execution potentially start right after calling `notify` ? Why do I have to give up the lock if it was not waiting on it ? – ng.newbie Jun 29 '17 at 18:15
  • The code is still operating in a `synchronized` block, the critical section. If it proceeded without reacquiring the lock it released when it called `wait()`, it would break the whole point of the feature. – Sotirios Delimanolis Jun 29 '17 at 18:17
  • @SotiriosDelimanolis Okay what is wrong in this statement - `wait()` tells the thread to go to sleep,give up its lock and wait for the lock until another thread releases it – ng.newbie Jun 29 '17 at 18:22
  • It's should say _The thread releases ownership of this monitor and **waits until another thread notifies threads waiting on this object's monitor** to wake up either through a call to the `notify` method or the `notifyAll `method. **The thread then waits until it can re-obtain ownership of the monitor** and resumes execution._ which is quoted from the Javadoc. – Sotirios Delimanolis Jun 29 '17 at 18:23
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/147973/discussion-between-ng-newbie-and-sotirios-delimanolis). – ng.newbie Jun 29 '17 at 18:25
  • @SotiriosDelimanolis The acquisition of the lock is not _just_ a side requirement: It's mean to discourage programmers from writing programs that _lose_ notifications. If I could write a program that used `wait()` and `notify()` without synchronization, then my program would not be able to guarantee that when some thread decided to call `o.wait()` for a condition, that some other thread would not make the condition true and call `o.notify()` *before* the first thread made it into the `o.wait()` call. – Solomon Slow Jun 29 '17 at 18:48

0 Answers0