Date: Sun, 19 Aug 2007 06:38:30 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Bruce Evans <brde@optusnet.com.au> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Lockless uidinfo. Message-ID: <20070819063348.M568@10.0.0.1> In-Reply-To: <20070819223351.R1132@besplex.bde.org> References: <20070818120056.GA6498@garage.freebsd.pl> <20070818220756.GH6498@garage.freebsd.pl> <20070819142214.O34036@delplex.bde.org> <20070819004949.U568@10.0.0.1> <20070819223351.R1132@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2007, Bruce Evans wrote: > On Sun, 19 Aug 2007, Jeff Roberson wrote: > >> On Sun, 19 Aug 2007, Bruce Evans wrote: > >>> atomic_*long() shouldn't exist (and doesn't exist in my version) since >>> longs should actually be long (twice as long as registers) and thus >>> especially epensive to lock. >> >> Well unfortunately this is not how the compiler implements them on the >> architectures that we support. So in this case long is 32bit on 32bit >> machines and 64bit on 64bit machines and as such requires each architecture >> to treat them specially. I don't think it's unreasonable to add an >> atomic_fetchadd_long() that conforms to the definition of long that is >> actually in use. > > The compiler has nothing to do with this. The implementation is FreeBSD's > and it is poor, like I said. Well this really has little to do with the problem at hand. The long decision has already been made and it's not practical to change it now. Adding apis that accept the types that we've decided on should not be crippled because you don't like the types. I agree that we can't have atomics that are wider than architectures support, but that isn't the case here. > > [Context lost to top posting] I included the context that I needed. > > Bruce >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070819063348.M568>