From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Could we replace SysV semaphores with latches? |
Date: | 2012-06-07 14:13:50 |
Message-ID: | 8321.1339078430@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 07.06.2012 07:09, Tom Lane wrote:
>> It strikes me that we have recently put together an independent but just
>> about equivalent waiting mechanism in the form of latches. And not only
>> that, but there's already a latch for each process. Could we replace
>> our usages of SysV semaphores with WaitLatch on the procLatch?
> Would have to performance test that carefully. We use semaphores in
> lwlocks, so it's performance critical. A latch might well be slower,
> especially on platforms where a signal does not interrupt sleep, and we
> rely on the signal handler and self-pipe to wake up.
By the time you've reached the point where you conclude you have to
block, all hope of high performance has gone out the window anyway,
so I can't get terribly excited about that. But in general, yeah,
our current implementation of latches could very possibly use some
more work to improve performance. I think we've latch-ified enough
code to make that worth doing already.
> Although perhaps we could improve the latch implementation. pselect()
> might perform better than the self-pipe trick, on platforms where it works.
AFAIK pselect does not fix the basic race condition: what if somebody
else does SetLatch just before you reach the blocking kernel call?
You still end up needing a self-pipe.
I would be more inclined to look into OS-specific primitives such as
futexes on Linux. (No idea whether those actually would be suitable,
just pointing out that they exist.) Our semaphore-based API was always
both overcomplicated and underspecified, but I think we have got latch
semantics nailed down well enough that implementations built on
OS-specific primitives could be a reasonable thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-07 14:18:55 | Re: XLog changes for 9.3 |
Previous Message | Robert Haas | 2012-06-07 14:04:20 | Re: Avoiding adjacent checkpoint records |