Alas, RISC operating systems do not have the CAS operation; therefore, Oracle, through its software, simulates the CAS operation. Obviously, some performance is lost. Oracle simulates the CAS operation by creating a pool of latches known as the KGX latches. If there is contention with Oracle's CAS operation simulation, latch:KGX will become the top wait event. If this occurs, as it has for some RISC systems, contact Oracle support.

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.