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
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 |