Date: Tue, 31 Oct 2000 12:42:53 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@wintelcom.net> Cc: Cedric Berger <cedric@wireless-networks.com>, Robert Watson <rwatson@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded enviro Message-ID: <XFMail.001031124253.jhb@FreeBSD.org> In-Reply-To: <20001031114756.W22110@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31-Oct-00 Alfred Perlstein wrote:
> * John Baldwin <jhb@FreeBSD.org> [001031 11:15] wrote:
>
> 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);
> }
The main cost of each of these is the 'lock', which is going
to drown out the rest of the cost. And actually, if you don't
care about the return value (which your code doesn't handle,
it just handles testing for zero, a requirement which I was not
aware of. Note that mine did more than that) you can just use
atomic_subtract(). Geez.
> Again, there's no nice MI abstraction going on with the code currently
> in place who says all arches can support uint ops atomically?
Uh, hang on before you blow your top. I have _*NEVER*_ said I
didn't like atomic_t. I was using 'int' for the sake of example.
> 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.
We aren't going to use mutexes to support atomic ops. atomic_cmpset
can be used to implement almost all atomic operations. See the IA64
atomic code, for example, which uses an atomic_cmpset() loop to implement
add, clear, set, and subtract.
> 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.
Actually, atomic_cmpset() loops are already used in a few places in
the code and aren't that hard to understand. But I'm not sure what
you don't like, refcount_update() or atomic_cmpset(). I was simply
showing how updating a refcount and returning the updated value can
now be trivially accomplished at _less_ cost than a mutex using our
existing atomic operations. I was not defining an API, I was giving
an example.
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.001031124253.jhb>