Re: dynamic shared memory and locks

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamic shared memory and locks
Date: 2014-01-06 15:14:09
Message-ID: 20140106151409.GL28320@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-01-06 09:59:49 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-01-06 10:35:59 +0200, Heikki Linnakangas wrote:
> >> 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
>
> I think it's a fine assumption. Code that could possibly do that should
> never get within hailing distance of being committed, because you are only
> supposed to have short straight-line bits of code under a spinlock.
> Taking another spinlock breaks both the "straight line code" and the "no
> loops" aspects of that coding rule.

I think it's fair to say that no such code should be accepted - but I
personally don't trust the review process to prevent such cases and not
all spinlock usages are obvious (e.g. LockBufferHdr). And having rules
that only cause breakage in configurations that nobody ever uses doesn't
inspire much trust in that configuration.
If we go that way, we should add an Assert preventing recursive spinlock
acquiration...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-06 15:29:06 Re: generic pseudotype IO functions?
Previous Message Andres Freund 2014-01-06 15:07:51 Re: cleanup in code