Date: Thu, 18 May 2000 17:00:35 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Terry Lambert <tlambert@primenet.com> Cc: cp@bsdi.com (Chuck Paterson), wes@softweyr.com (Wes Peters), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution Message-ID: <200005190000.RAA07951@rah.star-gate.com> In-Reply-To: Your message of "Thu, 18 May 2000 23:40:17 -0000." <200005182340.QAA11883@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > }Wouldn't it make more sense to provide an inversion-proof semaphore? > > }Or is that what they're doing? > > > > Not quite sure what you mean. The lock checking done > > now is to detect without actually having to have the deadlock > > occur the following > > > > thread 1 acquires lock "a" and then tries to acquire lock "b" > > thread 2 acquires lock "b" and then tries to acquire lock "a" > > > > > > There isn't really any automagic fix for this. > > Djikstra would disagree; this is the classic form for something > to which he would apply his "banker's algorithm" and pre reserve > both "a" and "b" for thread 1, before it ever became an issue. > > Deadlock avoidance is thus one way to deal with the problem. > > There are better soloutions that permit resource risk, however, > but they require that you be able to back completely out of a > partial transaction, and retry the whole thing, e.g. continuing: Hmm... Given that in an OS scenario one may not be able to restore the state of a partially committed transaction , I think that transaction style processing is not appropiate for exclusiveness of operations. Unless of course one is willing to virtualize the machine states and then commit a fully completed transaction which is somewhat what databases such as Oracle do. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005190000.RAA07951>