From owner-freebsd-smp Tue Oct 31 12:42:50 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 3B85137B4C5; Tue, 31 Oct 2000 12:42:47 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp241.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9VKfrf18112; Tue, 31 Oct 2000 12:41:53 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001031114756.W22110@fw.wintelcom.net> Date: Tue, 31 Oct 2000 12:42:53 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Reference count invariants in a fine-grained threaded enviro Cc: Cedric Berger Cc: Cedric Berger , Robert Watson , freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-Oct-00 Alfred Perlstein wrote: > * John Baldwin [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 -- 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