Re: [PATCH] Futex Asynchronous Interface

Vladimir Zidar (mr_w@mindnever.org)
12 Jun 2002 20:15:42 +0200


On Wed, 2002-06-12 at 18:50, Peter Wächtler wrote:

> >>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.
> >
>
> Oops, I see it already myself. We lack a way for saying who is/was owning
> the futex and so we can hardly tell who is waiting on this "unknown" lock.
> :-(

Which is not the case in 'nutex' implementation.

Take look:

http://www.mindnever.org/~mr_w/nutex_mod.tar.gz

-- 
Bye,

and have a very nice day !

- 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/