Date: Thu, 16 Oct 2003 23:22:17 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Doug Rabson <dfr@nlsystems.com> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys bus.h kobj.h param.h src/sys/kern subr_bus.c subr_kobj.c Message-ID: <20031016231222.I1298@gamplex.bde.org> In-Reply-To: <1066304172.20052.8.camel@builder02.qubesoft.com> References: <200310160916.h9G9GSqQ067982@repoman.freebsd.org> <1066304172.20052.8.camel@builder02.qubesoft.com>
index | next in thread | previous in thread | raw e-mail
On Thu, 16 Oct 2003, Doug Rabson wrote: > On Thu, 2003-10-16 at 12:16, Bruce Evans wrote: > > On Thu, 16 Oct 2003, Doug Rabson wrote: > > > ... > > > * Change the kobj method lookup algorithm to one which is SMP-safe. This > > > relies only on the constraint that an observer of a sequence of writes > > > of pointer-sized values will see exactly one of those values, not a > > > mixture of two or more values. This assumption holds for all processors > > > which FreeBSD supports. > > > > This assumption should be avoided by using atomic_load() (and > > atomic_store_mumble()). See a discussion of "atomicity of unlocked > > reads" last month. First implement atomic_load(). There is currently > > only atomic_load_acq_<type>(). "acq" gives acquire semantics which > > is more than what is needed here and our implementations may do more > > than what is required anyway for some arches. "<type>" is part of a > > bad API. > > Without using something like <type>, how can you know how much to read > (without abusing some kind of GCC language extension)? I don't want to > use atomic_load_acq_* since I don't care which order values are written > to the cache. sizeof(parameter) gives the size (but not the type) if atomic_foo(parameter) is a macro. The type isn't really needed in MD macros, especially for load/store. The macros for this would be almost as ugly as the ones for i386 pcpu accesses though. Using GCC extensions would probably be less ugly. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031016231222.I1298>