Thread

1. Win32 latch implementation revisited

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2010-09-14T09:56:32Z

   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.
   
   It was the separation of InitSharedLatch and OwnLatch steps that made 
   this possible, which is probably why this didn't occur to me earlier. 
   Separating those steps was definitely a good move.
   
   Unless someone sees a problem with this, I'll commit the attached patch 
   to do the simplification.
   
   -- 
      Heikki Linnakangas
      EnterpriseDB   http://www.enterprisedb.com
   

2. Re: Win32 latch implementation revisited

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-14T14:38:52Z

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.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