The Fast_Get function is repeatedly called during the Spin_Get function. The concept of spinning is the same for both mutexes and latches. However, when attempting to acquire a mutex, Oracle has hard-coded the maximum number of spins to 255, rather than the 2,000 used for latches, and it's not settable via an instance parameter. The thinking behind this is that, because the attempt to set the mutex's holder identifier occurs so elegantly and incredibly fast, if you're going to successfully acquire the mutex, you will get it quickly. If you don't, then you're not likely to acquire the mutex by spinning up to 2,000 times. So, instead of spinning 2,000 times and consuming precious CPU cycles, Oracle just puts the process to sleep for a bit and tries again.

The Mutex_Sleep function has the same objectives as with latches, but Oracle takes advantage of inherent mutex function calls. Figure 3-15 shows Oracle developers have a number of options to sleep an Oracle process. The desired sleep tactic is established when the mutex is created. In essence, it's part of the mutex creation process. Oracle developers can use mutex-specific sleep options, or they can create their own hybrid routine. But regardless, the general mutex options are to either yield the CPU, sleep, or block other processes from acquiring the mutex. By operating system tracing some Oracle server processes with heavy mutex contention, it appears Oracle is currently using the CPU yield option.

As you can see, Oracle has taken what was designed for high-concurrency thread control and incorporated-or perhaps retrofitted is a better word-mutexes into its serialization control scheme. The result is a stellar serialization scheme that is both flexible and fast. I suspect we'll continue to see Oracle kernel code developers take advantage of mutexes.