From owner-freebsd-current@FreeBSD.ORG Tue Feb 24 07:52:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA8616A4CE; Tue, 24 Feb 2004 07:52:32 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FB143D1D; Tue, 24 Feb 2004 07:52:32 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i1OFqB7E074413; Tue, 24 Feb 2004 07:52:15 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200402241552.i1OFqB7E074413@gw.catspoiler.org> Date: Tue, 24 Feb 2004 07:52:11 -0800 (PST) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200402241043.38696.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: kuriyama@imgsrc.co.jp cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org cc: mat@cnd.mcgill.ca cc: cg@FreeBSD.org Subject: Re: exclusive sleep mutex pcm0 (sound cdev) r = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 15:52:32 -0000 On 24 Feb, John Baldwin wrote: > On Tuesday 24 February 2004 10:27 am, Don Lewis wrote: >> I currently have some patches for the channel mutexes that are >> undergoing testing. Once these have been committed, I'll take another >> look at the "sound cdev" mutex. My current thought is to convert most >> uses of it to a lockmgr lock. > > Eek, why not a sx lock if you must go to a sleepable lock? That was my initial thought, but I was scared off by the following statement in the sx(9) man page: A thread may not own a shared lock and an exclusive lock simultaneously; attempting to do so will result in deadlock. My plan is to hold this lock across large portions of the open() and ioctl() methods (and possibly read() and write() as well). Some of these may call code outside of my direct control, such as methods in the hardware specific drivers, as well as things like malloc(). I'm concerned about causing a deadlock by violating the sx usage rules.