A bit like the VDSO in reverse: [LWN.net]

A bit like the VDSO in reverse:

Posted Feb 16, 2006 5:06 UTC (Thu) by AnswerGuy (guest, #1256)
Parent article: Robust futexes - a new approach

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

(Log in to post comments)

A bit like the VDSO in reverse:

Posted Feb 16, 2006 14:27 UTC (Thu) by mingo (subscriber, #31122) [Link]

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().

robust pthread mutexes too?

Posted Feb 16, 2006 21:47 UTC (Thu) by cdarroch (guest, #26812) [Link]

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.)

robust pthread mutexes too?

Posted Feb 16, 2006 22:51 UTC (Thu) by mingo (subscriber, #31122) [Link]

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.