From owner-freebsd-current@FreeBSD.ORG Mon Jun 12 06:59:16 2006 Return-Path: X-Original-To: current@FreeBSD.org 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 DB33616A41B for ; Mon, 12 Jun 2006 06:59:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EC5D43D45 for ; Mon, 12 Jun 2006 06:59:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3B9E346C0A; Mon, 12 Jun 2006 02:59:16 -0400 (EDT) Date: Mon, 12 Jun 2006 07:59:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <33721.1150091321@critter.freebsd.dk> Message-ID: <20060612075515.C26634@fledge.watson.org> References: <33721.1150091321@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org, Kris Kennaway Subject: Re: FILEDESC_LOCK() implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 12 Jun 2006 06:59:16 -0000 On Mon, 12 Jun 2006, Poul-Henning Kamp wrote: > In message <20060612054115.GA42379@xor.obsecurity.org>, Kris Kennaway writes: > >> I wonder if something better can be done with the funky home-grown locking >> in FILEDESC_LOCK() (see ) to make it more light-weight? > > It probably can. > > What's needed is a combined short/long lock, where you can either grab lock > for sleepable locking (like for instance sxlocks) or only grab a quick > version (like a mutex) for lightweight operations. There are a number of places where we interlock a sleep lock and a mutex: - File descriptors - Socket buffer sleep locks - Vnode sleep locks What we probably want is an sx_init_interlock() that allows us to provide the interlock for an sx lock, wich some variations on sx_*lock() to say we already hold the interlock. WITNESS will need some work to be happy with this. I'm not sure it's possible or desirable to get rid of the above sleep/mutex interlocks, since they're very much a defined part of the semantic. With socket buffers, for example, the mutex/interlock is used for data structure consistency, and the sleep lock is used to prevent interleaving of I/O operations. Separating the two locks entirely would significantly increase overhead, and they can't be combined as there are times when user threads are blocked from simultaneous I/O by the sleepable portion of the lock, but the stack needs to update the data structures (i.e., when a non-interleaved socket read is ocurring, and the stack needs to insert data into the buffer to be read). As things like this are a common idiom, supporting them better with our primitives makes some amount of sense. Whether things are sufficiently common to do this, only experimentation will tell. We don't want to end up with another lockmgr... Robert N M Watson Computer Laboratory Universty of Cambridge