On 2014-01-06 10:35:59 +0200, Heikki Linnakangas wrote:
> On 01/05/2014 07:56 PM, Robert Haas wrote:
> >Right now, storing spinlocks in dynamic shared memory *almost* works,
> >but there are problems with --disable-spinlocks. In that
> >configuration, we use semaphores to simulate spinlocks. Every time
> >someone calls SpinLockInit(), it's going to allocate a new semaphore
> >which will never be returned to the operating system, so you're pretty
> >quickly going to run out. There are a couple of things we could do
> >about this:
>
> 5. Allocate a fixed number of semaphores, and multiplex them to emulate any
> number of spinlocks. For example, allocate 100 semaphores, and use the
> address of the spinlock modulo 100 to calculate which semaphore to use to
> emulate that spinlock.
>
> That assumes that you never hold more than one spinlock at a time, otherwise
> you can get deadlocks. I think that assumptions holds currently, because
> acquiring two spinlocks at a time would be bad on performance grounds
> anyway.
I think that's a pretty dangerous assumption - and one which would only
break without just about anybody noticing because nobody tests
--disable-spinlock builds regularly. We could improve on that by adding
cassert checks against nested spinlocks, but that'd be a far too high
price for little benefit imo.
I am not convinced by the performance argument - there's lots of
spinlock that are rarely if ever contended. If you lock two such locks
in a consistent nested fashion there won't be a performance problem.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services