Date: Mon, 11 Sep 2000 13:05:13 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
To: Darren Reed <darrenr@reed.wattle.id.au>
Cc: smp@FreeBSD.ORG
Subject: Re: atomic_{add,subtract} functions.
Message-ID: <Pine.BSF.4.21.0009111246240.401-100000@besplex.bde.org>
In-Reply-To: <200009100915.UAA03343@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009111246240.401-100000>