| From: | "Min Xu (Hsu)" <xu(at)cs(dot)wisc(dot)edu> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, Pailloncy Jean-Gerard <jg(at)rilk(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Concurrent free-lock |
| Date: | 2005-01-25 04:43:29 |
| Message-ID: | 20050125044323.GB5746@cs.wisc.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-01-25 05:03:03 | Built-in casts for ltree |
| Previous Message | Jim C. Nasby | 2005-01-25 04:40:40 | Re: userlock changes for 8.1/8.2 |