Re: Race conditions in shm_mq.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Race conditions in shm_mq.c
Date
Msg-id CA+TgmoZCsBop8vODxzrQDXrQ2hzTyKqQYKiNLCNtUTeHGAWt8w@mail.gmail.com
Whole thread Raw
In response to Race conditions in shm_mq.c  (Antonin Houska <ah@cybertec.at>)
Responses Re: Race conditions in shm_mq.c  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Aug 6, 2015 at 10:10 AM, Antonin Houska <ah@cybertec.at> wrote:
> During my experiments with parallel workers I sometimes saw the "master" and
> worker process blocked. The master uses shm queue to send data to the worker,
> both sides nowait==false. I concluded that the following happened:
>
> The worker process set itself as a receiver on the queue after
> shm_mq_wait_internal() has completed its first check of "ptr", so this
> function left sender's procLatch in reset state. But before the procLatch was
> reset, the receiver still managed to read some data and set sender's procLatch
> to signal the reading, and eventually called its (receiver's) WaitLatch().
>
> So sender has effectively missed the receiver's notification and called
> WaitLatch() too (if the receiver already waits on its latch, it does not help
> for sender to call shm_mq_notify_receiver(): receiver won't do anything
> because there's no new data in the queue).
>
> Below is my patch proposal.

Another good catch.  However, I would prefer to fix this without
introducing a "continue" as I think that will make the control flow
clearer.  Therefore, I propose the attached variant of your idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Fwd: 9.5 release notes
Next
From: Robert Haas
Date:
Subject: Re: Race conditions in shm_mq.c