Thomas Gleixner wrote :
Patch d0aa7a70bf03b9de9e995ab272293be1f7937822 titled
"futex_requeue_pi optimization"
introduced user space visible changes to the futex syscall.
The patch is non-functional and there is no way to fix it proper before
the 2.6.22 release.
The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went
unanswered,
Sorry, but I passed lot of time on this last year without any answers or
comments from the community when I have sent my patches.
Now I'm working on something else and I can't spent more time on this for now...
Futexes are so complex that it is always difficult to investigate a problem in
only one or two hours...
and unfortunately it turned out that the concept is not
feasible at all.
Without robust futex, the concept works well, and the performance gain has been
proven.
It violates the rtmutex semantics badly by introducing
a virtual owner, which hacks around the coupling of the user-space
pi_futex and the kernel internal rt_mutex representation.
What you call a hack, is for me a design point. And if this is a hack, then I
think that we can say that futexes are based on a series of hacks...
But, okay, this is not very constructive, so...
Ulrich Drepper wrote :
>
> Indeed. A lot more discussion is needed to handle this correctly. No
> committed code in glibc so far uses the function so removal is no problem.
Once again, it's a pity that people didn't spent time to comment on this when I
was working on this.
Now, the work will probably just be lost...
--
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
