Date: Tue, 31 Oct 2000 11:47:56 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-smp@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Cedric Berger <cedric@wireless-networks.com> Subject: Re: Reference count invariants in a fine-grained threaded enviro Message-ID: <20001031114756.W22110@fw.wintelcom.net> In-Reply-To: <XFMail.001031111514.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Oct 31, 2000 at 11:15:14AM -0800 References: <20001031102110.V22110@fw.wintelcom.net> <XFMail.001031111514.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@FreeBSD.org> [001031 11:15] wrote:
>
> On 31-Oct-00 Alfred Perlstein wrote:
> > * Cedric Berger <cedric@wireless-networks.com> [001031 10:11] wrote:
> >>
> >>
> >> Robert Watson wrote:
> >> >
> >> [...]
> >> >
> >> > Rules for interactions between mutexes and reference-counted kernel
> >> > objects:
> >> >
> >> > Assumptions:
> >> >
> >> > - Objects with reference counts have a mutex that can protect their
> >> > reference count, and possibly other variables (or other instances). For
> >> > example, struct cred might have a mutex per instance, but all struct
> >> > prison's might use the same mutex.
> >> >
> >>
> >> Is there not a cheaper way to manage reference count then using mutexes?
> >> I would guess that all architectures must have hardware support (i.e.
> >> special
> >> assembly instruction) to atomically increment/decrement+read a 32-bit value
> >> in a multiprocessor environment
> >
> > Yes, but FreeBSD is has too many knights that say NIH!
>
> Huh? /me confused
>
> > This is where atomic refcounts would simplify the code however for some
> > reason everyone I've talked to prefers to have this sort of code:
>
> Really? Who have you been talking to? :) You can already do this now
> like so (the KTR code does this for example):
>
> static inline int
> refcount_update(int *ref, int delta)
> {
> int old;
>
> do {
> old = *ref;
> } while (!atomic_cmpset(ref, old, old + delta);
> return (old + delta);
> }
>
> Then just do:
>
> {
> ...
> /* add a reference */
> refcount_update(&foo->refcount, 1);
> ...
> /* remove a reference */
> refcount_update(&foo->refcount, -1);
> }
Hrm...
static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
int res = exp;
__asm __volatile (
" " MPLOCKED " "
" cmpxchgl %2,%3 ; "
" setz %%al ; "
" movzbl %%al,%0 ; "
"1: "
"# atomic_cmpset_int"
: "=a" (res) /* 0 (result) */
: "0" (exp), /* 1 */
"r" (src), /* 2 */
"m" (*(dst)) /* 3 */
: "memory");
return (res);
}
-vs-
static __inline int
atomic_dec_and_test(volatile atomic_t *v)
{
unsigned char c;
__asm __volatile("lock ; decl %0; sete %1"
: "=m" (v->a), "=qm" (c)
: "m" (v->a));
return (c != 0);
}
Again, there's no nice MI abstraction going on with the code currently
in place who says all arches can support uint ops atomically?
If you want to do it right you'll take the time to study the Linux
way of handling this and add the nessesary constructor/destructor
wrappers.
If you want to make it ugly or use heavyweight mutexes to support
simple atomic ops then you can go ahead and do it that way, when and
if I get a chance I'll make a patchset to fix it.
Your code is more expensive, less portable and harder to understand
than what I've presented, I really don't understand why you're so
convinced atomic_t isn't needed and somehow this atomic_cmpset_INT
is better.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001031114756.W22110>