Re: [PATCH] Futex Asynchronous Interface

[Hubertus Franke <frankeh@watson.ibm.com>]

On Wednesday 12 June 2002 05:16 am, Peter Wächtler wrote:
> Rusty Russell wrote:
> > In message <Pine.LNX.4.44.0206110951380.2712-100000@home.transmeta.com>
> > you wri
> >
> > te:
> >>Rusty,
> >> this makes no sense:
> >>
> >>D: This changes the implementation so that the waker actually unpins
> >>D: the page.  This is preparation for the async interface, where the
> >>D: process which registered interest is not in the kernel.
> >>
> >>Whazzup? The closing of the fd will unpin the page, the waker has no
> >>reason to do so. It is very much against the linux philosophy (and a
> >>design disaster anyway) to have the waker muck with the data structures
> >> of anything waiting.
> >
> > Good catch: now the fd is a "one-shot" thing anyway, making close
> > unpin the page makes more sense.  Tested patch below (against 2.5.21).
> >
> > FYI: I already violate this philosophy as I remove the waiter from the
> > queue when I wake them: this allows them to tell that they were woken
> > (waker does a list_del_init() on the waiting entry, so waiting knows
> > if (list_empty()) I was woken).
> >
> > It would be more natural for the waiter to examine the futex value,
> > and if it's still unchanged go back to sleep.  But this makes
> > assumptions about what they're using the futex value for.  For
> > example, we "PASS_THIS_DIRECTLY" value into the futex.  This requires
> > that one (and ONLY one) process waiting actually wakes up.
> >
> > This is why coming up with a primitive which allowed us to build posix
> > threads and fair queueing as well as "normal" unfair semantics took so
> > damn long.
>
> What are the plans on how to deal with a waiter when the lock holder
> dies abnormally?
>
> What about sending a signal (SIGTRAP or SIGLOST), returning -1 and
> setting errno to a reasonable value (EIO?)
>
> I couldn't find anything in susv3

I thing this was decided some time ago that we won't deal with this situation.
If we need to, the following needs to happen.

A) we need to follow a protocol to register the PID/TID id within the lock.
    Example of this is described in 
	"Recoverable User-Level Mutual Exclusion" by Phiilip Bohannon
            Proceedings of the 7th IEEE Symposium on Parallel and Distributed 
            Systems, 1995.

B) this again requires that some entity (kernel ?) knows about all locks, 
whether waited on in the kernel or not.

C) I believe we need a deamon that occasinally identifies dead locks.

Is it worth all this trouble? Or do we need two versions of the ?

The paper describes that for a Sun SS20/61 the safe spin locks obtained
only 25% of the performance of spinlocks.


-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)