Date: Mon, 12 Nov 2001 15:20:21 -0800 (PST)
From: Matthew Dillon <dillon@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.
Message-ID: <200111122320.fACNKLC07027@apollo.backplane.com>
References: <XFMail.011112150837.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111122320.fACNKLC07027>