United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6383015 : Biased thread scheduling in Java 5.0 on Linux and Solaris

Details
Type:
Bug
Submit Date:
2006-02-08
Status:
Closed
Updated Date:
2010-10-07
Project Name:
JDK
Resolved Date:
2006-02-13
Component:
hotspot
OS:
solaris_10
Sub-Component:
runtime
CPU:
sparc
Priority:
P3
Resolution:
Not an Issue
Affected Versions:
5.0u6
Fixed Versions:

Related Reports
Relates:

Sub Tasks

Description
With certain test applications Java 5.0 appears to persistently favor some threads at the expense of others on Linux and Solaris.

                                    

Comments
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.
                                     
2006-02-13
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.
                                     
2006-02-13



Hardware and Software, Engineered to Work Together