Re: Is the unfair lwlock behavior intended?

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is the unfair lwlock behavior intended?
Date: 2016-05-25 00:45:51
Message-ID: CAM3SWZQLnF+QhxJ6tA=1z7iRURPGfwyyVyKkV+W2NO8NetP-qA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 24, 2016 at 3:50 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Jim Gray's paper on the "Convoy phenomenon" remains relevant, decades later:
>>
>> http://www.msr-waypoint.com/en-us/um/people/gray/papers/Convoy%20Phenomenon%20RJ%202516.pdf
>>
>> I could believe that there's a case to be made for per-LWLock fairness
>> characteristics, which may be roughly what Andres meant.
>
> The problem is that half-way fair locks, which are frequently acquired
> both in shared and exclusive mode, have really bad throughput
> characteristics on modern multi-socket systems. We mostly get away with
> fair locking on object level (after considerable work re fast-path
> locking), because nearly all access are non-conflicting. But
> prohibiting any snapshot acquisitions when there's a single LW_EXCLUSIVE
> ProcArrayLock waiter, can reduce throughput dramatically.

That's a useful example of where things are different for different,
well known cases.

> I don't think randomly processing the wait queue - which is what the
> quoted paper essentially describes - is really useful here. We
> intentionally *ignore* the wait queue entirely if a lock is not
> conflicting, and that's what can prohibit exclusive locks from ever
> succeeding, because you essentially can get repetitions of:

My point about the paper is that it made me reconsider my assumption
that fairness, according to some definition, was essential for
something like LWLocks. The paper made me aware that it's perfectly
acceptable practice to make informed trade-offs around fairness for
what it calls "latches" (what we'd call LWLocks). Maybe that was
obvious to you, but it wasn't to me.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2016-05-25 01:04:10 Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)
Previous Message Robert Haas 2016-05-25 00:41:07 Re: Parallel safety tagging of extension functions