From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 08:29:46 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 D36A316A409 for ; Fri, 27 Apr 2007 08:29:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 665CC13C44C for ; Fri, 27 Apr 2007 08:29:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so670207ugh for ; Fri, 27 Apr 2007 01:29:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=JkWIibiJpqDmHqwsnWKiCYXa/v0/3M3NfjNCr4B1izyIZwS1EAkdz6ez/X0SbzHiLktVdpq2/sxbFO+d5plFbbrEaXqScgaCaFYZQZYzZBnStb7pwj4n+ckau/yyknJBdgVV5YZ1sNt7E/z5RC3YzBT7+9478yZxgdGvaLNi9oA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=AD9h1KVzlKJmEbjAH4oRfO0w2Lod4YO24Ir6lKTUvZVgEBO6B+LkO3MJcgvv7Jc9q4HPAHV/whdircoB9wwP4wEM4vGR8T3htDoOlwDi4qlCzB1cGNWE0/Gk8TDdBsD6bSeGKBGuEy14pTtJyHiAX5DqSQDXJD3vPCbayWj+ByM= Received: by 10.82.151.14 with SMTP id y14mr5214243bud.1177662581828; Fri, 27 Apr 2007 01:29:41 -0700 (PDT) Received: from ?172.31.5.21? ( [89.97.252.178]) by mx.google.com with ESMTP id y37sm1585309iky.2007.04.27.01.29.26; Fri, 27 Apr 2007 01:29:35 -0700 (PDT) Message-ID: <463225AF.9070708@FreeBSD.org> Date: Fri, 27 Apr 2007 18:32:47 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> In-Reply-To: <200704270748.49404.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: 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: attilio@FreeBSD.org 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 08:29:46 -0000 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. > >>> protecting has possibly been raped while you slept. I have seen too many >>> instances where people just called msleep and dropped the mutex they >>> held, picked it up again on wakeup, and then blithely continued on >>> without checking what happened while they were asleep. >> Basically, the idea you cannot hold "blocking" locks (mutexes and >> rwlocks) while sleeping, cames from the difference there is behind >> turnstiles and sleepqueues. >> >> Turnstiles are thought to serve syncronous events, for short period of >> time (or rather short) while sleepqueues are thought to serve >> asyncronous events, so that the path to be protected can be >> definitively bigger. If you fit in the situation you have to call >> first a blocking lock and later a sleeping lock, probabilly you are >> just using a wrong locking strategy and you should really revisit it. > > The suggestion is just for convenience. Usually you don't have a recursed > mutex to sleep on. It is just to catch some rare cases where you will end up > with a doubly locked mutex, which is not part of the ordinary code path. I > don't have such cases in the kernel of the new USB stack, but there are some > cases in the USB device drivers, which is due to some mutex locking moves. > Those I can fix. I don't think you got my point. I can understand this is for convenience and I can understand why you want it but definitively you should never have a recursed mutex, That's all. This is why msleep(), condvar() and lockmgr() panics if a recursed mutex is passed. Definitively, we mustn't cater a misbehaving approach with extra-hack in the kernel code. Attilio