Re: Synchronization primitives (Was: Re: An example of bugs for Hot Standby)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Hiroyuki Yamada <yamada(at)kokolink(dot)net>
Subject: Re: Synchronization primitives (Was: Re: An example of bugs for Hot Standby)
Date: 2010-01-20 18:49:03
Message-ID: 4B57501F.8030804@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Streaming Replication introduces a few places with a polling pattern
>> like this (in pseudocode):
>
>> while()
>> {
>> /* Check if variable in shared has advanced beoynd X */
>> SpinLockAcquire()
>> localvar = sharedvar;
>> SpinLockRelease()
>> if (localvar > X)
>> break;
>
>> /* Not yet. Sleep
>> pg_usleep(100);
>> }
>
> I trust there's a CHECK_FOR_INTERRUPTS in there ...
>
>> It would be nice to have a new synchronization primitive for that.
>
> Maybe. The lock, the variable, the comparison operation, and the sleep
> time all seem rather specific to each application. Not sure that it'd
> really buy much to try to turn it into a generic subroutine.

My point is that we should replace such polling loops with something
non-polling, using wait/signal or semaphores or something. That gets
quite a bit more complex. You'd probably still have the loop, but
instead of pg_usleep() you'd call some new primitive function that waits
until the shared variable changes.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-20 19:07:00 Re: Synchronization primitives (Was: Re: An example of bugs for Hot Standby)
Previous Message Simon Riggs 2010-01-20 18:47:10 Re: An example of bugs for Hot Standby