Date: Fri, 15 Nov 2002 03:15:23 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jake Burkholder <jake@locore.ca> Cc: Matt Jacob <mjacob@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm uma_dbg.c Message-ID: <20021115030008.L10861-100000@gamplex.bde.org> In-Reply-To: <20021110135825.B85338@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Nov 2002, Jake Burkholder wrote: > Apparently, On Sun, Nov 10, 2002 at 01:56:14PM -0500, > Jake Burkholder said words to the effect of; > > sparc64 can't do atomic operations on less than 32 bits, this needs > > a lock. > > fwiw this is in the man page: > > Certain architectures also provide operations for types smaller than > ``int''. > > char unsigned character > short unsigned short integer > 8 unsigned 8-bit integer > 16 unsigned 16-bit integer > > These must not be used in MI code because the instructions to implement > them efficiently may not be available. I think no arches should provide these and have removed them in my i386 version. They are (were) unused. I also want to remove atomic_*_long() on i386's. These are essentially useless on i386's with incorrectly sized longs (the default), since longs are essentially ints, but on i386's with 64-bit longs the current implementations just don't work. Correct implementations would need to use a lock, but this would defeat the main point of having atomic operations. atomic_*_long() are used mainly in drm and netgraph. atomic_t seems to be very bogus in drm. Some counters in drm and netgraph could reasonably be 64-bits, but longs don't give that on i386's and we have mostly avoided the issue of changing counters to uint64_t partly because making them atomic would be inefficient on 32-bit machine. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021115030008.L10861-100000>