On Wed, 12 Jun 2002, Peter Wächtler wrote:
>
> What are the plans on how to deal with a waiter when the lock holder
> dies abnormally?
That's why they are called FUTEX'es - they're fast. They're NOT SysV
semaphores, and they are done 99% in user space. The kernel doesn't even
_know_ about them until contention happens, and even then only in a rather
dim "somebody wants me to do this, but I don't know _what_ he is doing"
way.
> What about sending a signal (SIGTRAP or SIGLOST), returning -1 and
> setting errno to a reasonable value (EIO?)
There's just nothing the kernel _can_ do. The common case (by far) is that
the kernel has never seen the futex at all, since many uses are likely to
not have much contention. So when a user program dies holding such a
uncontended lock, the kernel simply _cannot_ do anything.
(The kernel also cannot do anything even for the contended locks, because
the whole interface is designed for speed and with the knowledge that the
kernel won't be able to fix stuff up, so the kernel doesn't actually have
enough information even in the contention case. See the "dim notion"
above).
Besides, if you have a threads package that uses some lock for mutual
exclusion, and a thread dies while holding the lock, there's nothign sane
anybody can do about it anyway. The data structures are likely to be in an
invalid state, and just making every other thread block on the lock until
you can attach a debugger is probably the closest to a _right_ thing you
can do.
In short: it's not a bug, it's a design feature, and it's very much
designed for efficiency.
Linus
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:25 EST