Re: Wait free LW_SHARED acquisition - v0.2

On Sat, Oct 25, 2014 at 1:50 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Oct 24, 2014 at 4:05 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
> wrote:
>>
>> On 2014-10-24 15:59:30 +0530, Amit Kapila wrote:
>> > > > and w.r.t performance it can lead extra
>> > > > function call, few checks and I think in some cases even can
>> > > > acquire/release spinlock.
>> > >
>> > > I fail to see how that could be the case.
>> >
>> > Won't it happen incase first backend sets releaseOK to true and another
>> > backend which tries to wakeup waiters on lock will acquire spinlock
>> > and tries to release the waiters.
>>
>> Sure, that can happen.
>> > > And again, this is code that's
>> > > only executed around a couple syscalls. And the cacheline will be
>> > > touched around there *anyway*.
>> >
>> > Sure, but I think syscalls are required in case we need to wake any
>> > waiter.
>>
>> It won't wake up a waiter if there's none on the list.
>
> Yeap, but still it will acquire/release spinlock.
>
>> > > > > And it'd be a pretty pointless
>> > > > > behaviour, leading to useless increased contention. The only time
>> > > > > it'd
>> > > > > make sense for X to be woken up is when it gets run faster than
>> > > > > the S
>> > > > > processes.
>> > > >
>> > > > Do we get any major benefit by changing the logic of waking up
>> > > > waiters?
>> > >
>> > > Yes.
>> >
>> > I think one downside I could see of new strategy is that the chance of
>> > Exclusive waiter to take more time before getting woked up is increased
>> > as now it will by pass Exclusive waiters in queue.
>>
>> Note that that *already* happens for any *new* shared locker that comes
>> in. It doesn't really make sense to have share lockers queued behind the
>> exclusive locker if others just go in front of it anyway.
>
> Yeah, but I think it is difficult to avoid that behaviour as even when it
> wakes
> Exclusive locker, some new shared locker can comes in and acquire the
> lock before Exclusive locker.
>
> I think it is difficult to say what is the best waking strategy, as priority
> for
> Exclusive lockers is not clearly defined incase of LWLocks.

Andres, where are we with this patch?

1. You're going to commit it, but haven't gotten around to it yet.

2. You're going to modify it some more and repost, but haven't gotten
around to it yet.

3. You're willing to see it modified if somebody else does the work,
but are out of time to spend on it yourself.

4. Something else?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company