It's pretty straightforward how a single latch can be used to control serial access to a memory structure. But, as we all know will eventually occur, when multiple processes need to access the same memory structure, contention results. As the term serial execution implies, one, and only one, process can hold the latch at any given time. This means that significant contention for the latch is very possible. Once again, our need to increase performance draws us toward parallelism. In simplistic terms, this requires multiple latches (sometimes called child latches). And once two latches exist, we also must have a facility to ensure that the two latch holders are not corrupting Oracle's memory structures.

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.