futex requeueing feature, futex-requeue-2.5.69-D3

In message <[email protected]> you write:

Perhaps I was reading too much into Linus' mail, but I read it as "don't obsolete the old interface and introduce a new one just because of some sense of aesthetics".

ie. it's not a to-be-obsoleted interface.

I think we're long past this being a productive thread, though. Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

no. The concept is: "dont cause the user any pain". Reshuffling the syscall internally and providing new interfaces for the feature to be exposed in a cleaner way is perfectly OK as long as this does not hurt anything else - and it does not in this case. New glibc will use the new syscalls and will fall back to the old one if they are -ENOSYS, so new glibc will work on older kernels as well. Old glibc will work with old kernels and new kernels as well. This is being done for other interfaces currently, this is the only mechanism to 'flush out' old syscalls gracefully.

the newer a kernel and a glibc is, the less 'fallback' happens - the faster the application is, so this compatibility scheme makes perfect sense both support-wise and technically. (not counting the speedup caused by the interface cleanups themselves)

not adding FUTEX_REQUEUE to the old syscall is the right solution - it was never exposed to anyone in this way, so old glibc doesnt know about it - and new glibc will never use the old interfaces.

any other disagreements?

Ingo

I don't think anyone disagreed with that (at least not me). The only thing I argued is that we don't need the usual flush-out period of two stable series because this syscall never was implemented in any relead stable kernel but rather a much shorter one so that this feature never hits a released stable kernel.

Linus disagrees strongly so we'll have to keep this crap around for five years - that's just yet another bit of bloat growing everyones kernel but no irreperable damage.

In message <[email protected]> you write:

I understand what you're saying, but I disagree.

See, I don't think the current interface is too ugly to live. Especially since you don't need to introduce a new arg to implement FUTEX_REQUEUE, so there's no immediate problem with it.

Do you understand what I'm saying? If so, we can agree to disagree, and it doesn't matter, because Linus will take your patch 8)

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

i think overloading a completely unrelated pointer (ie. overloading the timespec pointer with a futex pointer, depending on the value of the 'op' flag), within an already overcrowded multiplexing syscall is a 100% non-starter to begin with.

really, i dont see what your problem with the new syscalls are. Futexes started out as a special, limited hack for userspace threading, but by today they have become a first-class concept: generic, user-accessible waitqueues identified by the piece of VM they are located at. Very flexible, very useful and very fast.

eg. under LinuxThreads, all the pthread_* functions were assuming a shared VM. glibc functions like pthread_mutex_lock() only worked for 'threaded' setups - ie. threads sharing pagetables via CLONE_VM. LinuxThreads had to use thread pointers, lists and other constructs that made the library only useful for the limited 'threaded' case.

today, with NPTL + glibc, all these pthread APIs are 100% available for processes as well: all that is needed are the variables to be shared between two processes. Ie. it works for shared mmap()-ed regions, or SysV regions. Just #include <pthread.h> and use these rich locking APIs in your process-based applications. No need to go to threads to be able to use the pthread locking APIs. This, as far as i know, is a 'first' amongst unices.

While doing all this stuff we found a new, generic operation needed for these 'user-accissible hashed waitqueues': the ability to requeue waiting threads between two waitqueues, so that userspace can implement locking primitives more flexibly. This is a clean, generic operation nicely extending the already existing ability to wait on a waitqueue and to wake up a thread in a waitqueue. Glibc will happily use all the new syscalls. They are even slightly faster, and are much cleaner - and there's zero slowdown for code that used the old API. Plus historically we've constantly moved away from multiplexer syscalls. So it's precisely the right time to do this, and it's a win-win situation all over.

all that is needed now is some actual review of the new APIs from the conceptual angle (i've done that and i think they are okay, but more eyes see more), so that we make sure these are good and we wont need to discard any aspect of them anytime soon.

Ingo

In message <[email protected]> you write:

That's clear. But I just changed my mind 8)

Because if you're going to demux the syscall, it might be worth looking at FUTEX_FD: an "expected val" arg there might be worthwhile, because to use it currently I think NPTL does:

try to get futex
fd = sys_futex(FUTEX_FD...)
try to get futex again because of race

Have the futex_fd act like futex_wait, ie. return -EWOULDBLOCK if the value != expected value.

Sorry, I didn't comment because I thought your explanation, concept, analysis and code were all very neat.

Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.