As with all things Oracle, there is another level of detail. Mutex request serialization is ensured because, at an atomic level, the session identifier assignment operation is performed by a single compare-and-swap (CAS) operation. Because only a single instruction is executed, this single instruction becomes the point of serialization and control. This is a beautiful solution, because the point of serialization is below the business, the DBA, and the Oracle kernel code-down at the underlying operating system level. The lower the level the point of serialization occurs, the better. Not only is there less likely to be serialization issues because of application code or Oracle kernel code, but operations (for example, source code conditional statements versus a single CAS operation) will be significantly faster.

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.