I have patched the locking code to use POSIX semaphores (if appropriate
define is turned on) and it appears to work. Passed 100% of regression
tests in parallel mode. It turned out to be impractical to use existing
locking abstraction with POSIX semaphores due to the way they are
allocated. So I had to change prototype for IpcSemaphoreCreate() which
caused little changes in proc.c and spin.c. Other than that all changes
related to this are localized to ipc.c and ipc.h.
The code should be usable for number of other platforms, like QNX4,
Linux, Solaris and anything else with support of POSIX semaphores and
mmap(). It probably will provide some performance benefits (as I told
before, POSIX semaphores appear to be a LOT faster on Linux than SysV
ones).
The patch is made against 72b2 tarball (not CVS). Do you want me to just
post diffs or what do I do to get it merged? And where do I post it,
PORTS or PATCHES (as it might be interesting for many platforms)?
- igor
Tom Lane wrote:
>
> > Do you really need semaphores at all? They seem to be used for spinlocks
> > emulation and for synchronisation between postmaster & children. But
> > since you allocate one semaphore per backend, do you really need
> > *counting* synchronisation primitive or mutual exclusion would be
> > enough?
>
> We need the counting behavior since a wakening signal might be delivered
> before the waiting process reaches its semop, and it mustn't be forgotten.
> Since a single wait sema is used for multiple purposes, I believe there
> are cases where the count can go as high as 2, not 1. This might stop
> being a problem if LWLocks are implemented using separate mutexes, or it
> might not. There are comments in and around the locking code about lots
> of special cases and race conditions ... better study them.
>
> > I have locks implementation using POSIX mutexes, but there really should
> > be some way to choose locking scheme which suits particular hardware
> > best.
>
> We've had that argument several times now on pghackers; you might care
> to study the archives. I'm unconvinced that there's really any material
> benefit to be gained from trying to determine whether we're on SMP or
> not.
>
> regards, tom lane