LWN: Comments on "Robust futexes - a new approach"

Robust futexes - a new approach

philips — Mon, 03 Apr 2006 15:23:46 +0000

RedHat still dead set on fixing futexes???

After so many years of struggling with them I'd rather threw them away.

I still recall the frustration on RedHat mail lists after the release of RHL8. Nothing else but RPM itself was constantly hanging on call to futexes. The most frustrating part of course was the cold silence on the problem from RH employees... As if problem didn't exist...

Robust futexes - a new approach

addw — Sat, 18 Feb 2006 20:10:26 +0000

What happens if you grab one of these locks, and you fork() ?

What happens if you fork() and then exit() ? Will glibc go round freeing all of these things up - things that the parent still believes that it holds ?

robust pthread mutexes too?

mingo — Thu, 16 Feb 2006 22:51:21 +0000

Correct - these APIs are being standardized by POSIX, and this patchset aims at enabling them. Ulrich Drepper (glibc's maintainer) has already written the necessary glibc modifications to enable robust pthread_mutex_t mutexes, so once the new syscalls are accepted by the upstream kernel, glibc support should follow soon.

robust pthread mutexes too?

cdarroch — Thu, 16 Feb 2006 21:47:14 +0000

Would this allow for the development of functions similar to those found in Solaris, namely pthread_mutexattr_getrobust_np(), pthread_mutexattr_setrobust_np(), and pthread_mutex_consistent_np()? (The "_np" is for non-portable, if I remember correctly.)

A bit like the VDSO in reverse:

mingo — Thu, 16 Feb 2006 14:27:39 +0000

correct - this is about a complex and constantly changing userspace data structure being parsed by the kernel in certain cases. This is not the usual 'pass info the kernel' or 'pass info to userspace' kernel<->userspace data interaction that we normally do.

you are also right that there is a single (very fast) syscall per thread-lifetime. While this is already quite close to 'zero cost', and it is alot cheaper than the other solutions presented before, we could speed this up further by passing this pointer to sys_clone() - that would eliminate the extra syscall in the case of pthread_create().

A bit like the VDSO in reverse:

AnswerGuy — Thu, 16 Feb 2006 05:06:59 +0000

If I understand the description correction this is a little like the
virtual DSO (VDSO) in reverse.

The VDSO method is to provide a virtual library ... a kernel page containing
some userspace code ... which is mapped into the address space of every
process. These process can than access certain system functions (via SYSENTER on x86 processors that support it) without making system calls (via int 0x80H on x86). (On other x86 CPUs the virtual library page can be be implemented as old int 0x80H calls if necessary).

This patch allows a userspace process to register a pointer into its memory ... later allowing the kernel to peek into that memory region to find any futexes that are locked. So you suffer on system call and then the rest of the operations are memory accesses (and the kernel knows when to look in process space for them, and where to look).

Is that the gist of it?

JimD