Re: Move PinBuffer and UnpinBuffer to atomics

On Fri, Dec 11, 2015 at 6:34 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2015-12-11 15:56:46 +0300, Alexander Korotkov wrote:
> >
> > Yes, there is a cycle with retries in LWLockAcquire function. The case
of
> > retry is when waiter is waked up, but someone other steal the lock
before
> > him. Lock waiter is waked up by lock releaser only when lock becomes
free.
> > But in the case of high concurrency for shared lock, it almost never
> > becomes free. So, exclusive locker would be never waked up. I'm pretty
sure
> > this happens on big Intel machine while we do the benchmark. So,
relying on
> > number of retries wouldn't work in this case.
> > I'll do the tests to verify if retries happens in our case.

makes sense and if retries never happen, then I think changing
LWLockRelease()
such that it should wake the waiters if there are waiters on a lock and it
has not
waked them for some threshold number of times or something like that might
work.

>
> I seriously doubt that making lwlocks fairer is the right way to go
> here. In my testing the "unfairness" is essential to performance - the
> number of context switches otherwise increases massively.
>

Agreed, if the change being discussed hurts in any kind of scenario, then
we should better not do it, OTOH the case described by Alexander seems
to be genuine and I have seen similar complaint by customer in the past
for another database I worked with and the reason for the problem is same.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com