From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:07:22 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 7E2B316A400 for ; Fri, 27 Apr 2007 18:07:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6C57D13C4B0 for ; Fri, 27 Apr 2007 18:07:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:34:24 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EDEE3125B44; Fri, 27 Apr 2007 11:07:20 -0700 (PDT) Message-ID: <46323BEB.1020404@elischer.org> Date: Fri, 27 Apr 2007 11:07:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Matthew Dillon References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <200704270753.05438.hselasky@c2i.net> <200704271739.l3RHdG7a009988@apollo.backplane.com> In-Reply-To: <200704271739.l3RHdG7a009988@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 27 Apr 2007 18:07:22 -0000 Matthew Dillon wrote: > The real culprit here is passing held mutexes to unrelated procedures > in the first place because those procedures might have to block, in > order so those procedures can release and reacquire the mutex. > That's just bad coding in my view. The unrelated procedure has no > clue as to what the mutex is or why it is being held and really has no > business messing with it. [description of DFLY spinlocks removed for brevity] > > If I were to offer advise it would be: Just stop trying to mix water > and hot wax. Stop holding mutexes across potentially blocking procedure > calls. Stop passing mutexes into unrelated bits of code in order for > them to be released and reacquired somewhere deep in that code. Just > doing that will probably solve all of the problems being reported. Actually Matt, I don't think there is much argument here.. It has come to the time where locking needs a big broom, and I suspect that there will be such a broom activated at BSDCan. There is some work going on (by john and others) to 'unify and sanitise' the locking. We'll see where it goes. Or is that wax and hot water?