Messages in this thread | | | Subject | Re: [PATCH] Futex Asynchronous Interface | From | Vladimir Zidar <> | Date | 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/
| |