On Thu, Jun 7, 2012 at 10:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I would be more inclined to look into OS-specific primitives such as
> futexes on Linux. (No idea whether those actually would be suitable,
> just pointing out that they exist.) Our semaphore-based API was always
> both overcomplicated and underspecified, but I think we have got latch
> semantics nailed down well enough that implementations built on
> OS-specific primitives could be a reasonable thing.
I've been thinking about trying to futex-ify our spinlock
implementation, so that when we detect that the spinlock is contended
(or contended sufficiently badly?) we go into a long kernel sleep
(e.g. 10 s) and wait to be woken up. This might perform better than
our current implementation in cases where the spinlock is badly
contended, since it would avoid yanking the cache line around between
all the CPUs on the box. But I haven't yet, because (1) it'll only
work on Linux and (2) it's better to fix the problem that is causing
the contention rather than make the contention less expensive. Still,
it might be worth looking into.
I'm not sure whether there's a sensible way to use this for LWLocks
directly. It would be nice not to be doing the lock-within-a-lock
thing, but I don't know that I really want to maintain a completely
separate LWLock implementation just for Linux, and it's not obvious
how you're supposed to use a futex to implement a lock with more than
one lock mode.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company