Re: Wait free LW_SHARED acquisition - v0.2 - Mailing list pgsql-hackers

On 2014-06-17 20:47:51 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
> > On 2014-06-17 18:01:58 +0530, Amit Kapila wrote:
> > > On Tue, Jun 17, 2014 at 3:56 PM, Andres Freund <andres@2ndquadrant.com>
> > > > On 2014-06-17 12:41:26 +0530, Amit Kapila wrote:
> > I unfortunately still can't follow.
> 
> You have followed it pretty well as far as I can understand from your
> replies, as there is no reproducible test (which I think is bit tricky to
> prepare), so it becomes difficult to explain by theory.

I'm working an updated patch that moves the releaseOK into the
spinlocks. Maybe that's the problem already - it's certainly not correct
as is.

> > If Session-1 woke up some previous
> > waiter the woken up process will set releaseOK to true again when it
> > loops to acquire the lock?
> 
> You are right, it will wakeup the existing waiters, but I think the
> new logic has one difference which is that it can allow the backend to
> take Exclusive lock when there are already waiters in queue.  As per
> above example even though Session-2 and Session-3 are in wait
> queue, Session-4 will be able to acquire Exclusive lock which I think
> was previously not possible.

I think that was previously possible as well - in a slightly different
set of circumstances though. After a process releases a lock and wakes
up some of several waiters another process can come in and acquire the
lock. Before the woken up process gets scheduled again. lwlocks aren't
fair locks...

> > Somewhat unrelated:
> >
> > I have a fair amount of doubt about the effectiveness of the releaseOK
> > logic (which imo also is pretty poorly documented).
> > Essentially its intent is to avoid unneccessary scheduling when other
> > processes have already been woken up (i.e. releaseOK has been set to
> > false). I believe the theory is that if any process has already been
> > woken up it's pointless to wake up additional processes
> > (i.e. PGSemaphoreUnlock()) because the originally woken up process will
> > wake up at some point. But if the to-be-woken up process is scheduled
> > out because it used all his last timeslices fully that means we'll not
> > wakeup other waiters for a relatively long time.
> 
> I think it will also maintain that the wokedup process won't stall for
> very long time, because if we wake new waiters, then previously woked
> process can again enter into wait queue and similar thing can repeat
> for long time.

I don't think it effectively does that - newly incoming lockers ignore
the queue and just acquire the lock. Even if there's some other backend
scheduled to wake up. And shared locks can be acquired when there's
exclusive locks waiting.

I think both are actually critical for performance... Otherwise even a
only lightly contended lock would require scheduler activity when a
processes tries to lock something twice. Given the frequency we acquire
some locks with that'd be disastrous...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services