From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:36:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C3C016A401; Fri, 27 Apr 2007 18:36:24 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D3C1013C43E; Fri, 27 Apr 2007 18:36:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l3RIaLew013944; Fri, 27 Apr 2007 14:36:21 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 27 Apr 2007 14:36:21 -0400 (EDT) Date: Fri, 27 Apr 2007 14:36:21 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky In-Reply-To: <200704271917.29939.hselasky@freebsd.org> Message-ID: References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 18:36:24 -0000 On Fri, 27 Apr 2007, Hans Petter Selasky wrote: > On Friday 27 April 2007 15:14, Daniel Eischen wrote: >> >> When you hold a mutex, it should be for a very short time. And >> I agree with the other comment that all drivers should be multi-thread >> safe, so we shouldn't add cruft to allow for non MT-safe drivers. > > Yes, and no. > > Mutexes are used to get the CPU out of the code. Therefore you should not > lock/unlock all the time, to ensure that the locked time is as short as > possible. Because then you get double work checking the state after that you > lock a mutex again. Surely, in a "static" environment there is nothing to > check. But in a dynamic environment you need to check that "descriptors" of > all kinds are still present, after that you lock a mutex. Unlocking a mutex > allows "anything" to happen. Keeping a mutex locked prevents certain things > from happening. If you need to prevent "things" from happening, and it is at more of a macro level than micro level, then you probably want a condvar or barrier sort of synchroninzation, or possibly a rwlock. When the thread currently in the guts of your driver exits, he releases the CV or rwlock and allows another thread to enter (which possibly causes another "anything" to happen). -- DE