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.

So, I created a high-concurrency mutex experiment. The situation was similar to the single-process test, except now five sessions were involved, the cursor was opened and closed 200,000 instead of 500,000 times, and 6 samples were taken instead of 30 samples. The clock started when the first process began and stopped when all five processes completed their 200,000 cursor open and close loops. With mutexes disabled and the library cache latches enabled, the average test took 468.0 s +/- 14.7 s, 95% of the time. With mutexes enabled and the library cache latches disabled, the average test took 418.1 s +/- 7.4 s, 95% of the time. Mutexes reduced the test time by an incredible 11%. Statistically speaking, the performance difference is significant indeed! Also the mutex test times were less variable then standard latching, which means mutex usage will result in more consistent performance. As we hoped and expected, mutexes significantly improved cursor pinning performance.

If you are comfortable with the latching pseudocode shown in Figures 3-6 and 3-7, you will quickly grasp Oracle's mutex algorithm shown in Figures 3-15 and 3-16. As you can see, there are some interesting twists!