Re: Thinking about breaking up the BufMgrLock

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ReadBuffer needs to do a lookup to map the page ID to a buffer ID,
> which in principle requires only a shared lock on the page-to-buffer
> mapping (embodied in the buf_table hash table). Assuming success, it
> also needs to mark the buffer pinned and update the LRU-list position
> of the buffer. Marking pinned is certainly a buffer-local change,
> so we could imagine splitting up the BufMgrLock like this:

So the only reason you need the global lock is for the LRU updates?

This is a well understood problem. I remember it from my Systems class in
school. And searching on google finds lecture notes that match my memory that
there are other systems generally preferred to LRU precisely because they
don't require extensive list management in the critical path.

For example these slides:

http://www.cs.utexas.edu/users/lorenzo/corsi/cs372/03F/notes/11-20.pdf

They describe a few that could be relevant. I recall the clock sweep having
been recommended in class as having most of the best properties of LRU with
very low cost in the critical path.

To use a buffer you only have to set a single local flag indicating the buffer
has been used. A separate step advances circularly one buffer at a time
clearing the flags. If it finds any buffer that hasn't been used for a
complete cycle through the list then it can remove it, either entirely or
merely to a second list.

--
greg