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