From owner-freebsd-smp  Sun Sep 10  2:15:42 2000
Delivered-To: freebsd-smp@freebsd.org
Received: from darren2.lnk.telstra.net (darren2.lnk.telstra.net [139.130.53.33])
	by hub.freebsd.org (Postfix) with ESMTP id C4CA337B422
	for <smp@freebsd.org>; Sun, 10 Sep 2000 02:15:38 -0700 (PDT)
Received: (from root@localhost)
	by darren2.lnk.telstra.net (8.9.1/8.8.7) id JAA27723
	for <smp@freebsd.org>; Sun, 10 Sep 2000 09:15:35 GMT
From: Darren Reed <darrenr@reed.wattle.id.au>
Message-Id: <200009100915.UAA03343@avalon.reed.wattle.id.au>
Subject: atomic_{add,subtract} functions.
To: smp@freebsd.org
Date: Sun, 10 Sep 100 20:15:11 +1100 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


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.

Darren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message