Because mutexes are based on standard system calls, they form a base functionality on which Oracle can build to meet its specific objectives. For example, suppose Oracle wants greater control then the standard mutex spin call provides. Instead of using only the mutex spin request call, Oracle can add code to meet its objectives. This gives Oracle a tremendous amount of flexibility, and also allows Oracle to more easily integrate new facilities, like mutexes, into its existing code base.

There are a few very important and remarkable reasons why Oracle chose to start using mutexes. Besides a smaller memory footprint6 than latches (16 bytes compared to 112 bytes), mutexes give Oracle kernel developers more control over structure creation, reduce false contention, reduce the likelihood of the control structure being the bottleneck, and provide faster pinning times. Let's take a closer look at why Oracle was motivated to begin using mutexes.

Like latches, mutexes are associated with a memory structure or a memory structure piece. But, as shown back in Figure 3-2, latches are truly separate from their associated memory structures. While latch and mutex serialization objectives are the same, kernel developers can define a mutex to be part of the underlying memory structure or memory structure piece. This allows for increased memory structure granularity, with less concurrency control overhead and less false contention. If the mutex is defined as part of the memory structure or memory structure piece, and the memory structure is deallocated, then so is the mutex. For example, a mutex can be defined for each cursor. Oracle could also define a mutex for not only the parent cursor, but also any and all related cursors or cursor parts.