Re: FILEDESC_LOCK() implementation

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Mon, 12 Jun 2006 08:08:43 +0100 (BST)
On Mon, 12 Jun 2006, Poul-Henning Kamp wrote:

> In message <20060612075515.C26634_at_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
Received on Mon Jun 12 2006 - 05:08:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC