From owner-freebsd-arch  Mon Nov 12 15:20:36 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9503637B419; Mon, 12 Nov 2001 15:20:24 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.11.6/8.9.1) id fACNKLC07027;
	Mon, 12 Nov 2001 15:20:21 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 12 Nov 2001 15:20:21 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200111122320.fACNKLC07027@apollo.backplane.com>
To: John Baldwin <jhb@FreeBSD.ORG>
Cc: freebsd-arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>,
	Terry Lambert <tlambert2@mindspring.com>
Subject: Re: cur{thread/proc}, or not.
References:  <XFMail.011112150837.jhb@FreeBSD.org>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

:
:Yep.  They use a mutex for the refcount for now, but I still have patches that
:some people don't like for implementing a simple refcount API just using atomic
:operations.
:
:-- 
:
:John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/

    I haven't seen your patches but I like the idea of a simple API for
    incrementing and decrementing a refcnt_t type of variable that
    hides the underlying 'how'.  For example, on some architectures
    you could use atomic ops, on others you could use a small pool
    of mutexes.

    Specifically, I really dislike the mutex embedded in the ucred
    structure.  It is entirely unnecessary - a simple global pool
    of shared mutexes is sufficient, hashed by pointer address,
    or using atomic ops on architectures that support them.

    Something like this:

    /*
     * machine independant sys/refcnt.h
     */

    #ifndef ARCH_OVERRIDE_REFCNT

    typedef int refcnt_t;

    #endif

    ...

    /*
     * machine independant kern/refcnt.c
     */

    #ifndef ARCH_OVERRIDE_REFCNT

    #define MTX_POOL	32

    static struct mtx mtx_pool[MTX_POOL];

    /*
     * called in early startup to initialize
     * mutexes (if necessary)
     */
    void
    refcnt_init(void)
    {
	...
    }

    /*
     * Increment the ref counter.  panic if we
     * overflow.
     */
    void
    refcnt_bump(refcnt_t *rp)
    {
	/*
	 * architecture dependant. e.g. atomic op
	 * in I386, maybe a pool mutex for alpha, etc
	 * etc etc.
	 */
    }

    /*
     * Decrement the ref counter.  panic if we
     * overflow.  Returns the ref counter after
     * it has been decremented (typically used to
     * determine that the associated structure
     * is no longer in use).
     */
    int
    refcnt_drop(refcnt_t *rp)
    {
	/*
	 * architecture dependant. e.g. atomic op
	 * in I386, maybe a pool mutex for alpha, etc
	 * etc etc.
	 */
    }

    #endif

    You could have a default set of ref counter routines that
    use a global pool of mutexes to avoid having to implement
    them for each architecture, and you could have architecture
    overrides of those routines to implement architecture-specific
    optimizations.

    Similar pool-type functions (using the same pool) can be used
    to sequence structure deallocations / cloning / etc.  In
    fact, the one huge advantage of a pool mutex is that it
    is independant of the structure, so you don't race a
    deallocation routine when obtaining the mutex prior to
    checking that the structure is even valid.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message