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.

Oracle's flexible mutex implementation comes in very handy for extremely complex memory structures, like Oracle's library cache. When using a library cache latch, Oracle kernel code developers must associate multiple memory pieces with one of the library cache latches. Because library cache memory structures are highly interconnected, Oracle's latching capabilities result in a practical limitation (performance and coding complexity) as to how granularly the latches can be applied.