Date: Tue, 12 Sep 2000 05:15:59 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
To: Kevin Van Maren <vanmaren@fast.cs.utah.edu>
Cc: darrenr@reed.wattle.id.au, smp@FreeBSD.ORG
Subject: Re: atomic_{add,subtract} functions.
Message-ID: <Pine.BSF.4.21.0009120450460.5346-100000@besplex.bde.org>
In-Reply-To: <200009111526.JAA17010@fast.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Sep 2000, Kevin Van Maren wrote: > > 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 > > No, that's a "long long". A long is 64-bits on the alpha, whereas an > int is 32. Int and long are normally both 32 bits on x86. Long is abnormally 64 bits on x86-with-64-bit-longs :-). > > 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); > > ... > Is it really a big deal to know what type the variable is you're > manipulating? Perhaps if it is in a structure definition defined by > the OS; but then maybe there is a better way to handle that. If it is a typedefed type then its underlying type is not obvious, and might be machine-dependent. > If datatypes are going to be defined as explicitly-sized ints, then > operations on explicitly-sized ints should be provided,. This can be handled by the same code that handles basic types. The details for both can be hidden in macro using a sizeof ladder like the above (except on exotic machines where the size of an integral type doesn't determine the type up to signedness). 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.0009120450460.5346-100000>