From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>, 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-13 04:29:22 |
Message-ID: | m3y9gxt7j1.fsf@varsoon.denali.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Doug McNaught wrote:
> > 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).
>
> Strange that it doesn't wait for the lock. BSD/OS has:
It does wait. If the lock is already locked (atomic test in
userspace) the process makes a futex_wait system call, which puts the
process on a kernel waitqueue.
From what I can see, the new Linux locks are not a replacement for
POSIX locks/semaphores, they're simply a fairly clean way of
implementing them. They also just went into the development kernel,
so any appearance in production systems may take a few months at
least.
-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...
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Kovalenko | 2002-03-13 04:41:05 | Re: Lightweight locking primitive |
Previous Message | Matthew Kirkwood | 2002-03-13 00:51:37 | Re: Lightweight locking primitive |