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@us.ibm.com
> (w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003
> 
> Igor Kovalenko <Igor.Kovalenko@motorola.com> on 03/12/2002 04:48:23 PM
> 
> To:
> cc:    pgsql-hackers@postgresql.org, Hubertus Franke/Watson/IBM@IBMUS,
>        rusty@rustcorp.com.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