Heikki Linnakangas <heikki.linnakangas@enterprisedb.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