From owner-freebsd-current@FreeBSD.ORG  Mon Jun 12 07:08:45 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 2771516A473
	for <current@FreeBSD.org>; Mon, 12 Jun 2006 07:08:45 +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 B569D43D48
	for <current@FreeBSD.org>; Mon, 12 Jun 2006 07:08:44 +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 2725446C03;
	Mon, 12 Jun 2006 03:08:44 -0400 (EDT)
Date: Mon, 12 Jun 2006 08:08:43 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
In-Reply-To: <34009.1150095661@critter.freebsd.dk>
Message-ID: <20060612080504.W26634@fledge.watson.org>
References: <34009.1150095661@critter.freebsd.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: current@FreeBSD.org, Kris Kennaway <kris@obsecurity.org>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jun 2006 07:08:45 -0000


On Mon, 12 Jun 2006, Poul-Henning Kamp wrote:

> In message <20060612075515.C26634@fledge.watson.org>, Robert Watson writes:
>
>> 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.
>
> Sounds overly complicated to use.
>
> Why not just a sx_xlockfast() sx_xunlockfast() ? for some value of "fast" ?

At least in the VFS and socket code, you want a notion of acquiring both and 
dropping one, or upgrading/downgrading.  The logic tends to go something like 
this:

    SOCKBUF_LOCK(&sb->sb_rcv);
    /* blah blah blah */
    sb_lock(&sb->sb_rcv);	/* requires interlock */
    /* blah blah blah */
label:
    /* blah blah blah */
    sb_wait(&sb->sb_rcv);    /* drop interlock in msleep but keep sleep lock */
    /* blah blah blah */
    SOCKBUF_UNLOCK(&sb->sb_rcv);
    so->proto->pru_rcvd(foo);   /* drop interlock for layer boundary */
    SOCKBUF_LOCK(&sb->sb_rcv);
    if (!done)
         goto label;
    sb_unlock(&sb->sb_rcv);
    SOCKBUF_UNLOCK(&sb->sb_rcv);

I.e., you use the mutex for specific regions, dropping it for layer boundaries 
and sleeping, but hold the sleep lock for longer periods.

Robert N M Watson
Computer Laboratory
Universty of Cambridge