Re: Concurrent free-lock

From: Neil Conway <neilc(at)samurai(dot)com>
To: "Min Xu (Hsu)" <xu(at)cs(dot)wisc(dot)edu>
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 02:59:17
Message-ID: 1106621957.1780.79.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2005-01-24 at 19:36 -0600, Min Xu (Hsu) wrote:
> In any case, I think only when contention is high the non-blocking
> algorithms are worth looking at. So can someone shine some light
> on where the contention might be?

The major point of contention that has been identified in the past is
over the BufMgrLock, which is an LWLock that protects (1) the buffer
manager's lookup hash table (2) some aspects of the state of individual
buffers themselves (e.g. a buffer's flags and shared refcount -- see the
BufferDesc structure). Amazingly, there *are* lock-free hash table
algorithms (e.g. [1]), but at first glance they seem pretty complex, and
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.

There probably are other points of contention, but I think the
BufMgrLock has been the one that has stood out in the past -- if/when
that is resolved it will be easier to see what issues remain.

-Neil

[1] http://www.cs.rug.nl/~wim/mechver/hashtable/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-01-25 03:43:40 Re: userlock changes for 8.1/8.2
Previous Message Jim C. Nasby 2005-01-25 02:50:39 Re: userlock changes for 8.1/8.2