> And what is "right"? You have two problems:
>
> - The kernel has no idea of how many locks a dying process holds. The
> kernel only starts to know about a lock when another process has to
> wait for it.
There have been some discussions on this, it seems possible to make the
information available, to {kernel,lockmanager,other}.
> - Locked data may be in an inconsistent state. The kernel has no idea
> how to "repair" it.
But that's true for other things as well, like locks on regions of files.
That hasn't prevented locking from working and being useful.
What I don't like is the idea of processes sitting forever with their
thumb up their ass waiting for an unlock which isn't going to come. I have
an application like that, starts a few thousand threads and spins at
10-70k ctx/sec forever. It's (a) commercial binary-only, and (b) selected
by management against my recommendations. The vendor blames Linux, of
course, "threads don't work right," meaning "like Solaris" rather than
"like POSIX."
I would LOVE to see Andrea's "Child Run First" and optional part of the
mainline kernel, the patch seems to solve the hang, but doesn't play well
with other patches.
I don't see either of the above as show stoppers, although I agree they
are implementation issues.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/