If a shared mode mutex request is being made, the mutex's reference count is simply incremented by one, the holder identifier is cleared, and the Get_Mutex function returns TRUE. This operation is very elegant, very efficient, and very fast! It helps reduce the risk of the control structure, as opposed to access to the underlying memory structure, being the bottleneck.

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.