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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:26 EST