On Thursday, September 13, 2012 12:40:42 pm Bryan Venteicher wrote: > > Would it be possible to use atomic_load/store() instead of direct > > memory barriers? For example: > > > > I've been sitting on a (lightly tested) patch [1] for awhile that > does just that, but am not very happy with it. A lot of the fields > are 16-bit, which not all architectures have atomic(9) support for. > And I think the atomic(9) behavior on UP kernels does not provide > the same guarantees as on an SMP kernel (could have an UP kernel > on an SMP host).
That is the one thing I was worried about (the fields being defined to be 16-bit). I presume that is required by the virtio de facto standard? Shame we can't clue-by-four people putting 16-bit fields in these sort of things. :-P > I also found myself wanting an atomic_load_rel_*() type function. That would be odd I think. _rel barriers only affect stores, so there would be no defined ordering between the load and the subsequent stores. (With our current definitions of _acq and _rel.) If you need a full fence for some reason, than a plain mb() may be the best thing in that case. -- John Baldwin _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
