Suppose the session requests the mutex in exclusive mode. As before, the session tries to set the holder identifier to its session identifier. If successful, it makes sure that no other session has the mutex in shared mode by checking whether the reference count is zero. If the reference count is zero, the Fast_Get function returns TRUE, as will the Get_Mutex function, indicating the session now has the mutex in exclusive mode. This is key: the mutex's holder identifier was not cleared during the exclusive fast get request! This will cause all subsequent shared and exclusive mode requests to quickly fail, as they will not be able to set the mutex's holder identifier. This quick failure (due in part to the CAS operation) also helps to reduce the risk of the control structure being the performance bottleneck.

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.