Look closely at the Fast_Get function in Figure 3-16. The first If statement is not an equality test, but rather an attempt to assign the current session's identifier to the mutex's holder identifier. If this assignment is successful, then at this point, this session has control of the mutex. Any other session running the Fast_Get function will not be able to assign its session identifier to the holder identifier and will immediately return a FALSE. This ensures that only one session will be able acquire the mutex in either shared or exclusive mode at a time. In essence, Oracle is enforcing mutex request serialization in its Fast_Get function.

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.