Re: Concurrent free-lock

Поиск
Список
Период
Сортировка
От Min Xu (Hsu)
Тема Re: Concurrent free-lock
Дата
Msg-id 20050125044323.GB5746@cs.wisc.edu
обсуждение исходный текст
Ответ на Re: Concurrent free-lock  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: userlock changes for 8.1/8.2
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Built-in casts for ltree