Re: [PATCH] Futex Asynchronous Interface

[Linus Torvalds <torvalds@transmeta.com>]

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