From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 21:50:17 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 1645D16A407 for ; Thu, 26 Apr 2007 21:50:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id C602813C458 for ; Thu, 26 Apr 2007 21:50:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so413994ana for ; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PTwhlVgp5Du3S1kdbUrYI+TIcURKAH3Se8jud4LmUqNTedMPNipCmCYqhR4O3HkYC/QzzC9cJovePbEiGW0KlF7IK0f2pCYCYjITKgj/Hy4ss6jTnEyaDiddPVwC5zYqflB6gfD8V3Ysr9NBt/GwG20reM8gLT9EuCZHOVq/m4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RtI45W/I3QbdeQpo3F8hfB6SskjlVgmP6sqPij6atzrIDwdHptu+lw6IEpDLyUWe9xX1wZvkFJouj68rMDi1Ib4FuHM+ROgrcOJNGhP4DDwsZEgIaGvSsyHWAcJJPTqwzfCNColwv3MYSlGl/dbsUO80umQFjS5iCAZUgnDOoM4= Received: by 10.100.120.5 with SMTP id s5mr1517796anc.1177624216107; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) Received: by 10.100.178.1 with HTTP; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) Message-ID: <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> Date: Thu, 26 Apr 2007 23:50:16 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <46311708.5030002@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> X-Google-Sender-Auth: 22782b4d1654f6b2 Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 21:50:17 -0000 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 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. As you mention, it is not always possible to drop the blocking lock before to sleep since you can break your critical path and free the way for races of various genre. Even unlocking Giant, that is auto-magically done by sleeping primitives, can lead to very difficult to discover races (I can remind one in tty code, old of some months, that can be a good proof-of-concept for that). Attilio -- Peace can only be achieved by understanding - A. Einstein