Re: Lightweight locking primitive

Поиск
Список
Период
Сортировка
От Doug McNaught
Тема Re: Lightweight locking primitive
Дата
Msg-id m3n0xdv39z.fsf@varsoon.denali.to
обсуждение исходный текст
Ответ на Lightweight locking primitive  (Matthew Kirkwood <matthew@hairy.beasts.org>)
Ответы Re: Lightweight locking primitive  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Igor Kovalenko
Дата:
Сообщение: Re: Lightweight locking primitive
Следующее
От: teg@redhat.com (Trond Eivind Glomsrød)
Дата:
Сообщение: Re: Zlib vulnerability heads-up.