lock can do this. If the mutex owner is running, the requestor spins. If the owner isn't, the
requestor doesn't.
Unfortunately, in the user-level threads library, you generally cannot find out which thread holds a
mutex, and even if you could, the system call required to find out whether the thread in question
was on a CPU would be more expensive than just blocking. A clever trick in some operating
systems does make this possible.
A fair (and unanswered) question is: "Will the time saved by not spinning make up for the extra
time to use adaptive locks?" If you are using spin locks, you should know exactly how long a
critical section can be held. It may well prove faster to spin for the known time and ignore run
state entirely!
Java May Use Spin Locks
As the JVM is based on the underlying native threads library, it will use whatever type of mutex is
provided. For example, on Digital UNIX, and on Solaris 2.6 and above, all mutexes are actually
adaptive spin locks,[2] hence you will get them automatically. It is unlikely that you will ever
notice the difference.
[2]
If we claim that spin locks are not very useful, why do the OSs make them the default? Because
a few programs will benefit a great deal and most programs don't really care.
Timeouts
Condition variables and wait/notify also allow you to limit the sleep time. By calling
pthread_cond_timedwait() [object.wait(timeout)], you can arrange to be awakened
after a fixed amount of time, in case you're the impatient type. Should you know that the condition
ought to change within some time frame, you can wait for that amount of time and then figure out
what went wrong.
You can also use it simply as a thread-specific timer, although the standard timer functions
[sleep(), nanosleep(); Thread.sleep()] are more appropriate and easier to use. Be
aware that the system clock will limit the precision of the wakeup. A 10-ms resolution is typical.
If you want 100-µs precision, you'll probably have to use something highly vendor specific, and
you may have trouble getting such precision at all.
Once the wait time expires, the sleeping thread will be moved off the sleep queue and the wait will
return. For POSIX, pthread_cond_timedwait() will return a value, ETIMEDOUT, so you
know that it has timed out. In Java, there is no such indication and you are forced to keep track of
the time yourself to determine that wait() timed out as opposed to having been awakened
normally. (This is a bit of a hassle, and a wrapper function such as the one in Code Example 7-4 is
quite convenient.)
Indeed, in Java it is impossible to know if you've actually timed out. You can find out if the
current time is later than the timeout, but it's always possible that you received a spurious wakeup
before the timer expired but didn't see the wakeup until after expiration. This shouldn't be a
problem.
Elvis and the UFOs
Search WWH :
