On Thu, Jun 7, 2012 at 10:13 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
