RE: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1
From: Perez-Gonzalez, Inaky
Date: Thu Aug 05 2004 - 13:47:29 EST
> From: Ingo Molnar [mailto:mingo@xxxxxxx]
> * Perez-Gonzalez, Inaky <inaky.perez-gonzalez@xxxxxxxxx> wrote:
> > Fusyn aims to provide primitives to solve a bunch of gaps in POSIX
> > compliance related to mutexes, conditional variables and semaphores,
> > POSIX Advanced real-time support as well as adding mutex robustness
> > (to dying owners) and deep deadlock checking.
> the sched.c bits look clean enough.
The bit that scares me is the hook into effective_prio() in the
scheduler fast-path for the prio boost. It is a minimal op, but I know
how cautious are you guys on poking there.
> but, couldnt there be more sharing between futex.c and fusyn.c? In
> particular on the API side, why arent all these ops done as an extension
> to sys_futex()?
That's what I did initially and many people barked at me because it made
sys_futex even uglier. Somebody [I can't remember the thread and I cannot
find it] said that sys_futex() should have been split in a number of syscalls
from the beginning, not multiplexing--and that they should do that in 2.7
to ease up a transition.
As well, I need to take different arguments [flags for the fulocks, for example].
For the sys_ufuqueue_*(), it makes sense to do a redirection for simplification,
emulating the sys_futex() thingies, but for fulocks, they are completely
different beasts. It makes little sense, it is a locking interface, not a
> That would keep the glibc part much simpler (and more
> compatible) as well. You'd still get all the glory of implementing true
I'll work on the sys_futex() redirection to ufuqueues during today [let's
see if I can get something done before taking off on vacation] and as soon
as I come back, but for the ufulocks...the interface is too different. I
think it makes more sense to clean up the glibc implementation, make a truly
layered set of calls redirecting the lll_ stuff at compile time [and run
time where needed/desired] that would allow the user to select what he wants
to do (when in the know) and default to the best combination for the general
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/