Re: Lightweight locking primitive

You should take a look at pthread_mutex_setpshared(). May be they don't
in Linux, but that's just consequence of braindead implementation.

-- igor

Hubertus Franke wrote:
>
> Biggest difference, FUTEX work across address spaces, pthread_mutexes don't
> !
>
> Hubertus Franke
> Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh(at)us(dot)ibm(dot)com
> (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
>
> Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com> on 03/12/2002 04:48:23 PM
>
> To:
> cc: pgsql-hackers(at)postgresql(dot)org, Hubertus Franke/Watson/IBM(at)IBMUS,
> rusty(at)rustcorp(dot)com(dot)au
> Subject: Re: [HACKERS] Lightweight locking primitive
>
> 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