On Tue, May 24, 2011 at 11:38 AM, Noah Misch <n...@leadboat.com> wrote: >> Another random idea for optimization: we could have a lock-free array >> with one entry per backend, indicating whether any fast-path locks are >> present. Before acquiring its first fast-path lock, a backend writes >> a 1 into that array and inserts a store fence. After releasing its >> last fast-path lock, it performs a store fence and writes a 0 into the >> array. Anyone who needs to grovel through all the per-backend >> fast-path arrays for whatever reason can perform a load fence and then >> scan the array. If I understand how this stuff works (and it's very >> possible that I don't), when the scanning backend sees a 0, it can be >> assured that the target backend has no fast-path locks and therefore >> doesn't need to acquire and release that LWLock or scan that fast-path >> array for entries. > > I'm probably just missing something, but can't that conclusion become obsolete > arbitrarily quickly? What if the scanning backend sees a 0, and the subject > backend is currently sleeping just before it would have bumped that value? We > need to take the LWLock is there's any chance that the subject backend has not > yet seen the scanning backend's strong_lock_counts[] update.
Can't we bump strong_lock_counts[] *first*, make sure that change is globally visible, and only then start scanning the array? Once we've bumped strong_lock_counts[] and made sure everyone can see that change, it's still possible for backends to take a fast-path lock in some *other* fast-path partition, but nobody should be able to add any more fast-path locks in the partition we care about after that point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
