On Mon, Apr 1, 2013 at 11:55:07AM -0500, Merlin Moncure wrote: > > In fact, BufFreelistLock is really misnamed, because for the most > > part, the "free list" as we implement is going to be empty. What the > > BufFreelistLock is really doing is serializing the process of scanning > > for a free buffer. I think THAT is the problem. If we could arrange > > things so as to hold BufFreelistLock only for the amount of time > > needed to remove a buffer from a freelist ... we'd probably buy > > ourselves quite a bit. > > right. I'm imaging a buffer scan loop that looks something like > (uncompiled, untested) this. "TryLockBufHdr" does a simple TAS > without spin, returning the lock state (well, true if it acquired the > lock). usage_count is specifically and deliberately adjusted without > having a lock on the buffer header (this would require some careful > testing and possible changes elsewhere):
TAS does a CPU 'lock' instruction which affects the cpu cache. Why not just read the value with no lock? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
