How to understand the wait and notify method in Java Thread?

I am very confused in these two descriptions:

  • "The wait method blocks the calling thread and refuses to lock the monitor"
  • "The notification method unlocks one waiting thread, but does not refuse to lock the monitor"

Here are my questions:

  • I know that every object in Java has a lock, but what does “monitor lock” mean? is it the same as oject lock?

  • Why should the notification method refuse to lock the monitor?

  • If I try to make the object wait with the following code:

    class simpleTask extends Thread { int waitingTime; public simpleTask(int waitingTime) { this.waitingTime = waitingTime; } public void run() { synchronized(this) // this is a reference of current object { try { this.wait(waitingTime); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } 

Like the first description above, does this mean that the current object is locked by a synchronized keyword, and then the wait method releases the lock?

+7
source share
3 answers

I know that every object in Java has a lock, but what does “monitor lock” mean? Is it the same as locking an object?

Yes, it is one and the same. They are also sometimes called the mutex object and the primitive castle object. (But when someone talks about Lock , they talk about this Java interface ... which is another locking mechanism.)

Why should the notification method refuse to lock the monitor?

The notify method notify not leave a lock. Your code is obliged to refuse blocking (i.e., leave the synchronized block or return from the synchronized method) after returning the notify call.

Why is this necessary? Because any other thread that is currently waiting for this lock (in the wait(...) call) must re-lock this lock before the wait call completes.

Why did they design notify / wait as follows? So that they can be used to implement variable conditions.

Like the first description above, does this mean that the current object is locked by a synchronized keyword, and then the wait method releases the lock?

It is right. When a thread calls someObject.wait() , its lock on someObject freed ... and then again (on the same thread) before wait() returned. Of course, at the same time, someObject could be acquired and released several times by other threads. The fact is that when wait returns, the thread that called wait will have a lock.

+7
source
  • Yes, the monitor lock is the same as the object lock. If you do synchronized (object) , this is a lock.

  • In your example, the current object will refuse to block while waiting, the call to wait() stop locking. In another thread, notify() is called to wake the object up, and when the wait() call returns, it closes the lock again.

0
source

A monitor is a type of synchronization construct.

The reason for waiting for a lock to wait is because other threads can get a lock, for example, other threads that can wait. Also: Usually for a thread that wakes up other threads to block before releasing any threads to prevent a race condition.

For more on this, you should examine state variables (e.g. condvars).

0
source

All Articles