|
|
|
|
Back to newsletter 055 contents
You might think that two threads of the same priority both repeatedly contending for the same lock would overall get to lock it for the same number of times. But a fascinating point, backed by observed behavior, was raised by Billy Newport in this server side discussion.
Where the contention is bursty - which it often is in high-load systems - the operating system can favor one thread over the other because the thread releasing the lock is already running, and so has a lower context switching overhead to re-acquire the lock than the other waiting thread. The result can be that one thread gets a disproportionate amount of access through a critical section, starving other threads and unbalancing your application.
Solutions to this situation include yield()'ing more often; alternative patterns such as the Gatekeeper one that inspired the discussion referred to; explicitly queueing requests to acquire the resource (instead of using the implicit Java queues associated with each monitor that you get with synchronization); or at a higher level using communicating sequential processes (CSP), a framework that is currently being explained in three articles over at IBM developerworks.
In the newsletter we list our usual raft of articles, news and tools, and more. Kirk delves into reachability of objects, removing duplicates from lists, helping HotSpot compilation and much more in his roundup of performance discussions; and we have over 50 new performance tips extracted in concise form.
And a final mention - those of you in London on the 15th July might want to join me for lunch at the Sun central London offices for the latest JSIG seminar - see our first news item below.
Java performance tuning related news.
Back to newsletter 055 contents
