From owner-freebsd-arch  Thu May 18  8:57:48 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1])
	by hub.freebsd.org (Postfix) with ESMTP id 2C07737B50D
	for <arch@freebsd.org>; Thu, 18 May 2000 08:57:44 -0700 (PDT)
	(envelope-from cp@berserker.bsdi.com)
Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1])
	by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id JAA05148;
	Thu, 18 May 2000 09:57:19 -0600 (MDT)
Message-Id: <200005181557.JAA05148@berserker.bsdi.com>
To: Wes Peters <wes@softweyr.com>
Cc: Doug Rabson <dfr@nlsystems.com>, arch@freebsd.org
Subject: Re: A new api for asynchronous task execution 
From: Chuck Paterson <cp@bsdi.com>
Date: Thu, 18 May 2000 09:57:19 -0600
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.


	If you are talking about running processes in
order based on scheduling priority, this is propagated
though mutexs which have been blocked on.

Chuck


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message