From owner-freebsd-arch Thu May 18 15: 9:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 8D08237BB23 for ; Thu, 18 May 2000 15:09:27 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E8DB41CE1; Thu, 18 May 2000 15:09:25 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Doug Rabson Cc: Wes Peters , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: Message from Doug Rabson of "Thu, 18 May 2000 21:07:43 BST." Date: Thu, 18 May 2000 15:09:25 -0700 From: Peter Wemm Message-Id: <20000518220925.E8DB41CE1@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Thu, 18 May 2000, Wes Peters wrote: > > > Doug Rabson wrote: > > > > > > The BSD/OS mutex code includes a compile-time-selected debugging feature > > > which automatically detects locking hierarchy violations. Anyway, using a > > > mutex here doesn't add to locking complexity since the mutex would be > > > exited before calling the task's callback and re-entered after. > > > > Wouldn't it make more sense to provide an inversion-proof semaphore? > > Or is that what they're doing? > > I'm sure Chuck can describe it better than me. As I understand it, the > BSD/OS object is a simple counting mutex which comes in both blocking and > spinning forms. There is a set of strict rules for mutex nesting which the > debugging code uses to detect e.g. deadly embrace etc. That would be the WITNESS stuff, right? (for verifying and enforcing the rules) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message