From owner-freebsd-smp Sun Sep 10 19: 5:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 29C9337B422 for ; Sun, 10 Sep 2000 19:05:24 -0700 (PDT) Received: (qmail 11557 invoked from network); 11 Sep 2000 02:05:16 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 11 Sep 2000 02:05:16 -0000 Date: Mon, 11 Sep 2000 13:05:13 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Darren Reed Cc: smp@FreeBSD.ORG Subject: Re: atomic_{add,subtract} functions. In-Reply-To: <200009100915.UAA03343@avalon.reed.wattle.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 10 Sep 100, Darren Reed wrote: > Someone might want to expand that interface from being > > atomic_{add,subtract}_{char,short,int,long}() > > (what happened to quad?) to include these too: > > atomic_{add,subtract}_{8,16,32,64}() > > I (and others, I hope) aren't so much fussed with what you can do in half > a dozen asm. instructions on architecture X as having an interface which > can be used reliably. Afterall, what about {u_,}int{8,16,32,64}_t ? > > Personally, I don't care if the above macros turn out to be rather heavy > on some architectures (386, 486), heck, I'd even support them being > something like: > > #define atomic_add_foo(x, y) { mtx_enter(&mtx_foo, MTX_DEF); x += y; > mtx_exit(&mtx_foo); } > > if that is what was required. I care, and plan to remove atomic_add_long(), since it should not be implementable at a non-heavy cost (longs should be twice as wide as registers). I hope to use atomic_op(lvalue) and generate an error at compile-time if `lvalue' is not inherently atomic. The current functions can't be used without knowing too much about the data type or writing spam like: if (sizeof(lvalue) == sizeof(char)) atomic_add_char(lvalue); else if (sizeof(lvalue) == sizeof(short)) atomic_add_short(lvalue); ... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message