
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




Tue, 12 Mar 2002 17:55:46 -0500
"Hubertus Franke" <frankeh@us.ibm.com>
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

Tue, 12 Mar 2002 17:52:37 -0600
Igor Kovalenko <Igor.Kovalenko@motorola.com>
Re: Lightweight locking primitive