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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
