All the POSIX synchronization variables have nonblocking calls associated with them. [For
POSIX, pthread_mutex _trylock() and sem_trywait(). In Win32 there are timeouts
associated with each call.] These functions can be used for things such as spin locks and
complicated methods of coordinating threads while avoiding deadlock. It is very rare to ever use
these functions. Java doesn't have nonblocking synchronized sections; however, it is a simple
matter to write a nonblocking version of POSIX-style mutexes. But you probably don't want to do
that.
Spin Locks
Normally, you should hold a lock for the shortest time possible, to allow other threads to run
without blocking. There will occasionally be times (few and far between) when you look at the
blocking time for a mutex (about 42 µs on an SS4, see Appendix C, Timings) and say to yourself
"42 µs?! The other thread is only going to hold the mutex for 5 µs. Why should I have to block
just 'cause I stumbled into that tiny window of contention? It's not fair!"
You don't. You can use a spin lock and try again. It's simple. You initialize a counter to some
value and do a pthread_mutex_trylock()--that takes about 2 µs. If you don't get the lock,
decrement the counter and loop. Another 2 µs. Repeat. When the counter hits zero, give up and
block. If you get the mutex, you've saved a bunch of time. If you don't, you've only wasted a little
time.
In Code Example 7-3 we show the construction of a simple spin lock. Although this is a good
description of a spin lock, it's actually a poor implementation. We will discuss the issues and show
Example 7-3 Simple Spin Lock
/* Don't use this code! */
spin_lock(mutex_t *m) {
int i;
for ( i = 0; i < SPIN_COUNT; i++) {
if (pthread_mutex_trylock(m) != EBUSY)
return;
/* got the lock! */
}
pthread_mutex_lock(m);
/* give up and block. */
return;
/* got the lock after blocking! */
}
Spin locks can be effective in very restricted circumstances. The critical section must be short, you
must have significant contention for the lock, and you must be running on more than one CPU. If
you do decide you need a spin lock, test that assumption. Set the spin count to zero and time your
standardized, repeatable test case (you must have one!). Then set the spin count to a realistic value,
and time the test again. If you don't see a significant improvement, go back to regular mutex locks.
Spin locks are almost always the wrong answer, so be careful!
Adaptive Spin Locks
A refinement of spin locks, called adaptive spin locks, is used in many kernels. You can't build
them yourself and they are not generally provided by the vendor, but you might be interested in
knowing what they are.
If you could find out whether the thread holding the desired mutex was in fact currently running
on a CPU, you could make a more reasoned judgment as to whether or not to spin. An adaptive
Search WWH :
