Re: Condition variables vs interrupts

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Shawn Debnath <sdn(at)amazon(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: Condition variables vs interrupts
Date: 2019-12-24 02:10:49
Message-ID: CA+hUKGL9+KVNh5rRiG6e7Wim3xGizueuaBVK7W4WBLXEyqKcbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 21, 2019 at 2:10 PM Shawn Debnath <sdn(at)amazon(dot)com> wrote:
> On Fri, Dec 20, 2019 at 12:05:34PM +1300, Thomas Munro wrote:
> > I think we should probably just remove the unusual ResetLatch() call,
> > rather than adding a CFI(). See attached. Thoughts?
>
> I agree: removing the ResetLatch() and having the wait event code deal
> with it is a better way to go. I wonder why the reset was done in the
> first place?

Thanks for the review. I was preparing to commit this today, but I
think I've spotted another latch protocol problem in the stable
branches only and I'd to get some more eyeballs on it. I bet it's
really hard to hit, but ConditionVariableSleep()'s return path (ie
when the CV has been signalled) forgets that the the latch is
multiplexed and latches are merged: just because it was set by
ConditionVariableSignal() doesn't mean it wasn't *also* set by die()
or some other interrupt, and yet at the point we return, we've reset
the latch and not run CFI(), and there's nothing to say the caller
won't then immediately wait on the latch in some other code path, and
sleep like a log despite the earlier delivery of (say) SIGTERM. If
I'm right about that, I think the solution is to move that CFI down in
the stable branches (which you already did for master in commit
1321509f).

Attachment Content-Type Size
0001-Don-t-reset-latch-in-ConditionVariablePrepare-master.patch application/octet-stream 2.3 KB
0001-Don-t-reset-latch-in-ConditionVariableP-backbranches.patch application/octet-stream 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-12-24 02:57:12 Re: Should we rename amapi.h and amapi.c?
Previous Message Kyotaro Horiguchi 2019-12-24 02:08:07 Re: archive status ".ready" files may be created too early