Re: Reducing overhead of frequent table locks

On Tue, May 24, 2011 at 11:38 AM, Noah Misch <noah@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