Re: Concurrent free-lock - Mailing list pgsql-hackers

From Min Xu (Hsu)
Subject Re: Concurrent free-lock
Date
Msg-id 20050125044323.GB5746@cs.wisc.edu
Whole thread Raw
In response to Re: Concurrent free-lock  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On Tue, 25 Jan 2005 Neil Conway wrote :
> Amazingly, there *are* lock-free hash table
> algorithms (e.g. [1]), but at first glance they seem pretty complex, and

It is a little scary when I read the lock-free hash table algorithm
needs a theorem prover to prove its correctness. I'd guess maintaining
such code is hard.

> I'm not sure how much they would help (we'd still need some form of
> synchronization to protect access to buffer flags etc.) I think the
> better route to fixing this problem is just rethinking how we do locking
> in the bufmgr.

I completely agree. Ultimately, if a piece of code has "true" contention,
i.e. the contention was not due to coarse-grain locking, then perhaps
redesigning the algorithm is a better solution. I certainly have no
idea what is the code of the bufmgr looks like. May the problem here
be coarse-grain locking?



pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: userlock changes for 8.1/8.2
Next
From: "Jim C. Nasby"
Date:
Subject: Built-in casts for ltree