Does Java monitor's wait set has a priority over entry set?

user_9591240 0
Viewed 1148

I would like to ask you a question related to multithreading in Java.

I have a monitor and multiple threads are eager to own it. Also inside the critical section this.wait() is invoked based on some conditions.

AFAIK, the monitor has 2 sets of threads:

  • entry set - where just arrived threads congregate and wait for their turn to own the monitor
  • wait set - where this.wait() threads that are waiting to be awakened

But how do they compete when notify/notifyAll is called? Do threads from wait set have a priority in acquiring the monitor over threads in entry set or do they move to entry set?

Can I be sure that in case of notify the next executed thread will be one from the wait set?

barrier mutex concurrency multithreading java
1 Answers

No. The scheduler is in charge of which thread gets the lock next. It might be one from the wait set that got notified. It might be a thread that is just arrived and hasn't entered the wait set. Assuming the thread that just got notified will get the monitor next is not safe.

The standard advice is to call wait in a loop where we check the condition being waited on:

synchronized (lock) {
    while (!condition) {
        lock.wait();
    }
    ...

That way when a thread comes out of a wait, it makes the same check as any thread that hasn't waited yet to know whether to progress or not.

If you need fairness, where you want the longest-waiting thread to acquire the lock next, then you might try one of the explicit Locks from java.util.concurrent.locks, such as ReentrantLock, but read the fine print:

The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. Note however, that fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock. Also note that the untimed tryLock method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting.

user_2173240
Related