Date: Thu, 12 Oct 2000 14:22:57 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Chuck Paterson <cp@bsdi.com>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: we need atomic_t Message-ID: <20001012142257.S272@fw.wintelcom.net> In-Reply-To: <200010122102.OAA16802@usr07.primenet.com>; from tlambert@primenet.com on Thu, Oct 12, 2000 at 09:02:50PM %2B0000 References: <200010122007.OAA18121@berserker.bsdi.com> <200010122102.OAA16802@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [001012 14:03] wrote: > > Lets say its not a counter, but something that > > gets bits or'd into it. Seems that it better be > > big enough to hold the bit that is going to be or'd > > in? We have to worry about this today, I don't see > > this changing just because we declare it atomic. > > To heck with "atomic", now we are just complaining about the > lack of foresight of the X3J11 committe in copping out on > giving us sized types in the C language itself. > > I think if "it's big enough", there isn't a problem. You > will never use something like this for hardware registers, > since hardware registers are sized, so as long as you commit > to either "at least 16 bits" or "at least 32 bits", it's not > a problem: just only ever use 16 or 32 bits, and so what if > some bits are "wasted", if all you care about is atomicity? My unspoken minimum precision was going to be 24 bits, for situations where that wasn't enough the idea was to provide a atomic64_t, but only if the demand was reasonable. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001012142257.S272>