Re: Lightweight locking primitive - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: Lightweight locking primitive
Date
Msg-id m3n0xdv39z.fsf@varsoon.denali.to
Whole thread Raw
In response to Lightweight locking primitive  (Matthew Kirkwood <matthew@hairy.beasts.org>)
Responses Re: Lightweight locking primitive  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Igor Kovalenko <Igor.Kovalenko@motorola.com> writes:

> 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?

They're basically the same thing.  Currently, pthread_mutexes on Linux
(implemented in glibc) are fairly gross in the contended case, since
there is no clean way to wait for lock release, and they interact
fairly nastily with signal semantics.  The futex patches create a new
system call which lets you cleanly wait for a locked futex (an
unlocking task checks for waiting lockers and calls into the kernel
for wakeups if it finds any).

There's no reason that POSIX mutextes and semaphores couldn't be
implemented on top of futexes, usable both in threaded and
multiprocess shared-memory environments. 

> 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?

I interpret the above as meaning: contended case (blocked in
futex_wait syscall or whatever it's called) can be cleanly interrupted
and by a signal and restarted automatically.

> RW locks are defined by POSIX too and can be implemented by mutex +
> condvar. I wonder what is wrong with those...

There's no conflict between POSIX locks and futexes; the latter are
just a good, new way to implement the former.

>                                           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...

Yes, having mutexes and semaphores shareable by different processes
is one of the benefits of the new locks as I understand them.

-Doug
-- 
Doug McNaught       Wireboard Industries      http://www.wireboard.com/
     Custom software development, systems and network consulting.     Java PostgreSQL Enhydra Python Zope Perl Apache
LinuxBSD...
 


pgsql-hackers by date:

Previous
From: Igor Kovalenko
Date:
Subject: Re: Lightweight locking primitive
Next
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: Zlib vulnerability heads-up.