Java: waiting on synchronized block, who goes first?

views:

111

answers:

+2 Q:

Java: waiting on synchronized block, who goes first?

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)?

+1 A:

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()

org.life.java 2010-10-15 07:16:37

Any idea how Hotspot handles this?

Thilo 2010-10-15 07:18:34

If I take these two answer together with Thread priorities not resulting in OS thread priorities on Linux (at least in most situations), those priorities don't seem to do a lot...

Thilo 2010-10-15 07:30:39

@Thilo It depends on implementation. I Can't say that is OS dependent.

org.life.java 2010-10-15 07:32:47

@Thilo, are you planning to write code depending on the behaviour?

Thorbjørn Ravn Andersen 2010-10-15 07:49:54

@Thorbjoern: No, just curious.

Thilo 2010-10-15 07:56:19

+2 A:

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 2010-10-15 07:18:25

+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 2010-10-15 07:22:56

I agree that would have been the "natural" choice.

Mikkel Gadegaard 2010-10-15 07:39:04

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 2010-10-15 14:31:07

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 2010-10-15 07:48:38

Are you saying that higher priority does go first?

Thilo 2010-10-15 07:49:20

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 2010-10-15 08:06:12

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 2010-10-18 23:12:44

ansaurus

tags:

views:

answers:

Java: waiting on synchronized block, who goes first?

related questions