Java Thread Priorities demystified
By Dave on Aug 27, 2006
The mapping between Java thread priorities and native thread priorities in J2SE has a long and tortured history. If you're interested, I'd recommend reading the following, which I wrote as part of the release notes for J2SE 5.0. That description applies to 6.0 as well.
In the future I expect to add support on Solaris for mapping thread priorities in the RT and FX scheduling classes as well as for the IA and TS classes. I'm also considering adding flags that would (a) allow low priority Java threads to be placed in the Solaris FX class or the Linux SCHED_BATCH/SCHED_IDLE class, and, (b), where the process has appropriate permissions, to force threads running at Java priorities above a certain threshold into the the RT scheduling class. Alternately, a native interface encapsulated in a .so or .dll that allowed "pluggable" priority mapping policies would be more general and perhaps of more use. Drop me a comment if you feel strongly either way.
Finally, it's worth noting that thread priorities are not currently used in notify(), notifyAll(), or when picking a potential successor to wake up in monitorexit. That's likely to change, of course.
As an aside, under Solaris, threads with higher effective priorities will have shorter quanta, at least in the IA or TS scheduling classes. (Read the man pages for dispadmin and priocntl for details). If your program is compute-bound, you may be able to reduce the voluntary preemption rate by forcing the program to run at lower effective priority, yielding long slices, which in turn results in less preemption, and amortizing the penalty associated with the cache reload transient. You might also consider the FX scheduling class. Beware, of course, that if your process is competing with other, higher priority processes, it'll be at a disadvantage and receive fewer relative cycles from the scheduler. But if the system is otherwise idle, FX or lower priorities can be of benefit.