On Mon, Dec 19, 2005 at 09:11:18PM +0100, Ingo Molnar wrote:
> i think we also need to look at the larger picture. If this really is a
> bug that hid for years, it shows that the semaphore code is too complex
> to be properly reviewed and improved. Hence even assuming that the mutex
> code does not bring direct code advantages (which i'm disputing :-), the
> mutex code is far simpler and thus easier to improve. We humans have a
> given number of neurons, which form a hard limit :) In fact it's the
> mutex code that made it apparent that there's something wrong with
> semaphores.
True, but then the original semaphores weren't designed with fairness in
mind so much as being able to operate quickly. The commodity SMP hardware
that we have today has significantly different characteristics than the
first dual Pentium I used. I think there is significant room for improving
the implementation while still making it as tight and lean as possible. To
that end, adding state diagrams that make it easier to visualise what is
going on would be a big help. With that in place, it will be easier to
provide optimized fast paths with understandable logic.
> Just look at the semaphore implementations of various architectures,
> it's a quite colorful and inconsistent mix. Can you imagine adding
> deadlock debugging to each of them?
Agreed.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
-
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]
