With certain test applications Java 5.0 appears to persistently favor some threads at the expense of others on Linux and Solaris.
Comments
EVALUATION
This is a duplicate of 6316090 and being closed.
As discussed in 6316090 Java makes no scheduling guarantees and applications should not be relying on any system provided notion of fairness. The changes in behaviour that have been observed are a side-effect of implementation changes to improve general throughput and performance. Additionally there are interactions with the underlying system scheduler that affect the observed behaviour.
In 1.5.0 the monitor queuing policy is "mostly prepend", which is essentially LIFO except that every N queue additions are done as an append rather than a prepend. Prepending yields better throughput/performance by trying to allow the most recently blocked thread to run next in the expectation that it will still have a warm cache etc. The occasional append prevents actual starvation, but the resulting behaviour can still be grossly "unfair" if expecting FIFO ordering.
13-02-2006
WORK AROUND
The VM option -XX:AppendRatio=N can be used to control how often an append is done rather than an append. If set to 0 then every enqueue will be an append and the observed behaviour will be "fair" if desiring FIFO like ordering.
The correct fix here is in the application however: if an application requires that different threads are guaranteed to make progress then it must program in those progression guarantees through the protocols that it implements. As noted with 6316090 also consider using some of the facilities in java.util.concurrent.locks to achieve fair synchronization.