svn commit: r240427 - head/sys/dev/virtio

John Baldwin jhb at freebsd.org
Thu Sep 13 20:11:27 UTC 2012


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


More information about the svn-src-all mailing list