Re: Lightweight locking primitive

From: Doug McNaught <doug(at)wireboard(dot)com>
To: Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, frankeh(at)us(dot)ibm(dot)com, rusty(at)rustcorp(dot)com(dot)au
Subject: Re: Lightweight locking primitive
Date: 2002-03-12 22:18:16
Message-ID: m3n0xdv39z.fsf@varsoon.denali.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)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 Linux BSD...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hubertus Franke 2002-03-12 22:55:46 Re: Lightweight locking primitive
Previous Message Igor Kovalenko 2002-03-12 21:48:23 Re: Lightweight locking primitive