Latches and mutexes can be used to pin a memory structure. Every mutex has a variable called the reference count. It contains the number of processes that are currently referencing the mutex (in shared mode). Oracle uses the reference count to determine if an object is being pinned. If the reference count is greater than zero, Oracle knows the object is pinned and cannot be deallocated. When an object is being pinned, the corresponding mutex's reference count is incremented by one. When the object is unpinned, the reference count is reduced by one. As long as the reference count is greater than zero or the mutex is being exclusively held, every Oracle process knows the memory structure is being referenced by some process, and therefore it cannot be deallocated.

As you might expect, mutexes are expected to perform the pinning operation much more quickly than latches can do pinning. A quick test showed mutex pinning is significantly faster than latch pinning. For this test, a simple Oracle Database 10g Release 2 one-table SQL statement cursor was repeatedly opened and closed 500,000 times in a very tight PL/SQL loop by a single session. The database server contained a single four-core CPU. This test was repeated 30 times and the wall clock time recorded. The hidden instance parameter _kks_use_mutex_pin (a setting of true enables mutexes when supported) determined if mutexes were used instead of library cache latches.

With mutexes disabled, both the library cache and the library cache pin latches were very active. However, with mutexes enabled, neither latch had any activity (that is, latch gets were zero)! With mutexes disabled and the library cache latches enabled, the average test took 20.00 s +/- 1.07 s, 95% of the time. With mutexes enabled and the library cache latches disabled, the average test took 19.90 s +/- 0.98 s, 95% of the time. While the difference may seem irrelevant, statistically, they are indeed very different. Even at a 95% confidence level, this test indicates mutexes did indeed improve performance. Also keep in mind that this is a simple, single-session cursor open and close test. We would expect mutex performance to be even more pronounced in a high-concurrency test.