From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 13:14:36 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 C39F416A400 for ; Fri, 27 Apr 2007 13:14:36 +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 8A4CF13C484 for ; Fri, 27 Apr 2007 13:14:36 +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 l3RDEAgN010070; Fri, 27 Apr 2007 09:14:11 -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 09:14:11 -0400 (EDT) Date: Fri, 27 Apr 2007 09:14:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky In-Reply-To: <200704270748.49404.hselasky@c2i.net> Message-ID: References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> 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 13:14:36 -0000 On Fri, 27 Apr 2007, Hans Petter Selasky wrote: > On Thursday 26 April 2007 23:50, Attilio Rao wrote: >> 2007/4/26, Julian Elischer : >>> The reason that mutexes ever recurse in the first place is usually >>> because one piece of code calls itself (or a related piece of code) in a >>> blind manner.. in other words, it doesn't know it is doing so. The whole >>> concept of recursing mutexes is a bit gross. The concept of blindly >>> unwinding them is I think just asking for trouble. >>> >>> Further the idea that holding a mutex "except for when we sleep" is a >>> generally bright idea is also a bit odd to me.. If you hold a mutex and >>> release it during sleep you probably should invalidate all assumptions >>> you made during the period before you slept as whatever you were > > That is not always correct. If you run your code in a separate > thread/taskqueue, then you simply wait for this thread/taskqueue to complete > somewhere else. This is basically when I need to exit mutexes. I know there are reasons why we have msleep(), but use of msleep() and recursive mutexes should raise be frowned upon. If you want to sleep, that's why we have condvar's. And if you are releasing a synchronization lock in a different thread, then why aren't you using condvar's wrapped by mutexes() to protect the internal state? 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. -- DE