On 2015-06-10 10:25:32 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Unfortunately there's no portable futex support. That's what stopped us > > from adopting them so far. And even futexes can be significantly more > > heavyweight under moderate contention than our spinlocks - It's rather > > easy to reproduce scenarios where futexes cause significant slowdown in > > comparison to spinning in userspace (just reproduce contention on a > > spinlock where the protected area will be *very* short - i.e. no cache > > misses, no branches or such). > > Which, you'll note, is the ONLY case that's allowed by our coding rules > for spinlock use. If there are any locking sections that are not very > short straight-line code, or at least code with easily predicted branches, > we need to fix those before we worry about the spinlock mechanism per > se.
We haven't followed that all that strictly imo. While lwlocks are a bit less problematic in 9.5 (as they take far fewer spinlocks), they're still far from perfect as we manipulate linked lists while holding a lock. We malso do lots of hard to predict stuff while the buffer header spinlock is held... > Optimizing for misuse of the mechanism is not the way. Agreed. I'm not particularly interested in optimizing spinlocks. We should get rid of most. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
