From owner-freebsd-arch Thu May 18 17: 1: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 4AD3F37B546 for ; Thu, 18 May 2000 17:01:03 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id RAA07951; Thu, 18 May 2000 17:00:35 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <200005190000.RAA07951@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert 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 In-reply-to: Your message of "Thu, 18 May 2000 23:40:17 -0000." <200005182340.QAA11883@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 17:00:35 -0700 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > }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