On Mon, Jul 2, 2012 at 12:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What this seems to me to show, though, is that pthread mutexes are not
> fundamentally a better technology than what we have now in spinlocks.
> The problem is that the spinlock code is not adapting well to very high
> levels of contention. I wonder whether a better and less invasive fix
> could be had by playing with the rules for adjustment of
> spins_per_delay. Right now, those are coded without any thought about
> high-contention cases. In particular I wonder whether we ought to
> try to determine which individual locks are high-contention, and behave
> differently when trying to acquire those.
The delay code is stupider than it could be, in that it sleeps without
regard to what's happening elsewhere in the system. The futex stuff
was interesting to me because it potentially provides a way to sleep
"until something interesting happens" rather than "for a fixed amount
of time". But it's unclear to me what exactly we'd have to do to
squeeze out a win, or even whether it's possible.
The other side of this equation, too, is that a decent argument can be
made that spinlock contention should be fixed by reducing contention
rather than by contending more efficiently. The latter might help get
performance from "terrible" up to "poor" in a range of circumstances,
but I don't think it's going to get us all the way to "good".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company