Explicit Locks - Java Concurrency in Practice - page 327

Performance is a moving target; yesterday's benchmark showing that X is faster than Y may
already be out of date today.
13.3. Fairness
The ReentrantLock constructor offers a choice of two fairness options: create a nonfair
lock (the default) or a fair lock. Threads acquire a fair lock in the order in which they re-
quested it, whereas a nonfair lock permits barging : threads requesting a lock can jump ahead
of the queue of waiting threads if the lock happens to be available when it is requested.
( Semaphore also offers the choice of fair or nonfair acquisition ordering.) Nonfair
ReentrantLock s do not go out of their way to promote barging—they simply don't pre-
vent a thread from barging if it shows up at the right time. With a fair lock, a newly requesting
thread is queued if the lock is held by another thread or if threads are queued waiting for the
lock; with a nonfair lock, the thread is queued only if the lock is currently held. [4]
Wouldn't we want all locks to be fair? After all, fairness is good and unfairness is bad, right?
(Just ask your kids.) When it comes to locking, though, fairness has a significant performance
cost because of the overhead of suspending and resuming threads. In practice, a statistical
fairness guarantee—promising that a blocked thread will eventually acquire the lock—is of-
ten good enough, and is far less expensive to deliver. Some algorithms rely on fair queueing
to ensure their correctness, but these are unusual. In most cases, the performance benefits of
nonfair locks outweigh the benefits of fair queueing.
Figure 13.2 shows another run of the Map performance test, this time comparing HashMap
wrapped with fair and nonfair ReentrantLock s on a four-way Opteron system running
Solaris, plotted on a log scale. [5] The fairness penalty is nearly two orders of magnitude.
Don't pay for fairness if you don't need it.