On 03/09/10 17:51, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> On 02/09/10 23:13, Tom Lane wrote:
>>> Also, using sig_atomic_t for owner_pid is entirely not sane.
>
>> Hmm, true, it doesn't need to be set from signal handler, but is there
>> an atomicity problem if one process calls ReleaseLatch while another
>> process is in SetLatch?
>
> If there is *any* possibility of that happening then you have far worse
> problems than whether the field is atomically readable or not: the
> behavior will be unpredictable at just slightly larger timescales.
> This is the reason why I think it'd be better if ReleaseLatch simply
> didn't exist. That'd discourage people from designing dynamic latch
> structures, which are fundamentally going to be subject to race
> conditions.
Each Walsender needs a latch, and walsenders come and go. I first
experimented with had no ReleaseLatch function; instead any process
could call WaitLatch on any shared latch, as long as only one process
waits on a given latch at a time. But it had exactly the same problem,
WaitLatch had to set the pid on the Latch struct to allow other
processes to send the signal. Another process could call SetLatch and
read the pid field, while WaitLatch is just setting it. I think we'll
have to put a spinlock there, if we can't assume that assignment of
pid_t is atomic. It's not the end of the world..
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com