Re: Win32 latch implementation revisited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: Win32 latch implementation revisited
Date: 2010-09-14 14:38:52
Message-ID: 5490.1284475132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> It just occurred to me that the Windows latch implementation goes
> through a lot of trouble to dynamically assign the shared Windows event
> handles to the latches in OwnLatch, but there's really no reason why
> they can't be statically assigned in InitSharedLatch instead. We have to
> allocate the same amount of event handles anyway.

> That makes the implementation a lot simpler, eliminating the shared
> memory block dedicated to latches altogether, and all the related
> bookkeeping. We no longer need NumSharedLatches() function anymore
> either, each InitSharedLatch call can allocate a new event handle directly.

That sounds real good. The only possible downside I can see is this:

> + * InitSharedLatch needs to be called in postmaster before forking child
> + * processes, usually right after allocating the shared memory block
> + * containing the latch with ShmemInitStruct. The Unix implementation
> + * doesn't actually require that, but the Windows one does.

But realistically I think we have to insist on InitSharedLatch being
done during shared memory setup anyway, else there will be race
condition issues. So no objection here.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2010-09-14 14:57:14 Re: pg_ctl emits strange warning message
Previous Message Tom Lane 2010-09-14 14:19:18 Re: Report: removing the inconsistencies in our CVS->git conversion