Matthew Kirkwood wrote:
>
> Hi,
>
> It seems that the Linux kernel will very shortly acquire a lightweight
> userlevel locking primitive (called futexes), thanks primarily to Rusty
> and Hubertus. It looks to be very useful for the sort of locking that
> databases of various types need to do.
>
> They have a bunch of rather nice properties:
I am curious how 'futexes' are different/better than POSIX (pthread
style) mutexes?
>
> a) low overhead in the no-contention case - a single locked
> instruction on i386
should be same for pthread_mutex_lock()
> b) no kernel overhead for non-contended locks - make as
> many as you like, the kernel memory cost is only
> O(number of locks with waiters)
Well it can't have kernel overhead for non-contended locks if a
non-contended lock is one opcode, can it?
> c) are interruptible / restartable across signals
Not sure what 'restartable' means? Do you mean locking primitives would
restarted by kernel when interrupted by signals? Like kernel calls with
SA_RESTART set? How that would be possible if kernel does not even know
about non-contended locks?
> d) the name :-)
>
> They don't do:
>
> a) deadlock detection
> b) cleanup on process exit -- the kernel doesn't know who
> had the lock, so it can't help here
>
> A reader/writer version is available, though it's currently implemented
> with two futexes. Spin-for-a-while-before-sleeping versions are planned.
>
RW locks are defined by POSIX too and can be implemented by mutex +
condvar. I wonder what is wrong with those... At the same time Linux has
POSIX semaphores which can not be shared across processes, making them
quite useless. Fixing that could help postgres quite a bit more I
think...
-- igor