One solution is have a master latch coordinating and controlling many slave latches, but that would mean additional kernel code for coordination. Time spent on latch acquisition is not for actually accessing the underlying memory structure, but rather for gaining the authorization to do so. It is a sad situation indeed when the performance issue resides in the acquisition process itself, not the memory structure access. Using a master/slave latching architecture could easily result in too much time spent acquiring a latch.

Another solution is to structure the multiple latches to take advantage of the underlying memory structure itself. For example, if the memory structure consists of 500 linked lists,3 then instead of having one latch controlling access to all 500 lists, have 100 latches, each related to 5 linked lists. Referring back to Figure 3-2, it would be like control structure CS101 being associated with memory structure MS1-A, MS1-B, ... MS1-n, and control structure CS375 being associated with memory structure MS2-A, MS2-B, ... MS2-n. Oracle takes this approach with at least two memory structures: the least recently used list and the cache buffer chains.

Years ago, it was common for Oracle's single least recently used (LRU) list to have latching contention issues. LRU lists are used to ensure that the popular buffers remain in the buffer cache and to help server processes quickly locate free and unpopular buffers. The LRU lists are not used to find or locate a specific block; that is the purpose of the cache buffer chains.