14

This question is inspired by this other question.

If multiple threads are waiting on a synchronized block, and the lock becomes available, who goes first? Is it by thread priority (and then first-come-first-served)?

And do the same rules apply for notify (with multiple waiting threads)?

Community
  • 1
  • 1
Thilo
  • 257,207
  • 101
  • 511
  • 656
  • 1
    If 'fair locks' are what you are looking for, then look at the java.util.concurrent package. As an example, ReEntrantLocks are fair. The fairness comes from the fact that priority is given to longest waiting threads, analogous to 'Aging' concept in process scheduling. – questzen Oct 15 '10 at 08:04

4 Answers4

8

According to this guy: http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html

Java issues no guarantees about the sequence. So I guess it is not based on thread priority

I'll try to look further for an explanation on how Java actually decides who goes first.

Mikkel Gadegaard
  • 376
  • 1
  • 4
  • 12
  • 3
    +1 Interesting. Turns out that the locks in the concurrency package have an optional fairness mode, in which case they work fifo. If not, it is arbitrary. I would have thought that thread priority should play a role here. – Thilo Oct 15 '10 at 07:22
  • I agree that would have been the "natural" choice. – Mikkel Gadegaard Oct 15 '10 at 07:39
  • 5
    Fairness comes at a cost, and the predictability is achieved at the expense of big throughput drop. Also, the fairness requirement would prevent tons of optimizations that VM might do in implementing lock acquisitions (things like thin spin-locks, etc.). – sjlee Oct 15 '10 at 14:31
  • 1
    One question abouth this: if thread1 is the holder of the monitor and other threads are waiting, is it possible for thread1 to unlock and race "around" and get the lock again before ANY of the already waiting threads? – dmansfield Nov 24 '14 at 15:58
  • 2
    @dmansfield I can't give any definitive answer, but it SEEMS like that's what's happening in my code. If anybody has a more official answer, I'd like to hear it. – Erhannis Aug 26 '15 at 20:57
6

Someone else mentioned the availability of fair locks. If you really care who goes first, then you may have a real-time problem. In that case, you can make use of RTSJ, wherein the ordering and other semantics of lock acquisition is specified. The specifics are available in the RTSJ Spec under Synchronization. Quoting from the rationale section:

Java's rules for synchronized code provide a means for mutual exclusion but do not prevent unbounded priority inversions and thus are insufficient for real-time applications. This specification strengthens the semantics for synchronized code by mandating priority inversion control, in particular by furnishing classes for priority inheritance and priority ceiling emulation. Priority inheritance is more widely implemented in real-time operating systems and thus is required and is the initial default mechanism in this specification.

andersoj
  • 22,406
  • 7
  • 62
  • 73
1

for your second Question

one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.

From http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Object.html#notify()

jmj
  • 237,923
  • 42
  • 401
  • 438
0

It depends on thread priority and thread scheduling algorithm and also the lock on the synchronized block is not "fair". This means that if there are 2 waiting threads with the same priority and the first thread waited more than the second thread that doesn't necessarily mean that the first thread will be executed first.

punkers
  • 107
  • 2
  • Are you saying that higher priority does go first? – Thilo Oct 15 '10 at 07:49
  • no sorry I'm not saying that, I missed that case. I'm saying that even a thread with higher priority could be executed after a thread with lower priority because of the fairness. This is because unfair lock provide weaker liveness guarantees that require that all threads will eventually acquire the lock. – punkers Oct 15 '10 at 08:06
  • The lock is unfair and the only way that higher priority threads are more likely to successfully acquire the lock than lower priority ones is that the lower priority threads are starved of execution time itself. – Paul Stelian Feb 05 '19 at 11:38