From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 22:09:35 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 08A0216A401; Fri, 27 Apr 2007 22:09:35 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id DB12013C458; Fri, 27 Apr 2007 22:09:34 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms073.mailsrvcs.net ([172.18.12.131]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JH600CLEG7ILDD1@vms046.mailsrvcs.net>; Fri, 27 Apr 2007 17:09:18 -0500 (CDT) Received: from 208.253.138.194 ([208.253.138.194]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Apr 2007 17:09:18 -0500 (CDT) Date: Fri, 27 Apr 2007 17:09:18 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [208.253.138.194] To: Julian Elischer , Hans Petter Selasky Message-id: <2782784.9021177711758431.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 27 Apr 2007 22:25:26 +0000 Cc: Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net 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 22:09:35 -0000 >From: Julian Elischer >Basically you shouldn't have a recursed mutex FULL STOP. We have a couple >of instances in the kernel where we allow a mutex to recurse, but they had to be >hard fought, and the general rule is "Don't". If you are recursing on >a mutex you need to switch to some other method of doing things. >e.g. reference counts, turnstiles, whatever.. use the mutex to create these One typical problem is when someone holds a mutex and needs to call a function that also tried to get the mutex. The typical solution for it is to provide two versions of this function, one expecting the mutex being already held by the caller, the other being a wrapper that grabs the mutex and then calls the actual worker function. -SB