svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net
Attilio Rao
attilio at freebsd.org
Mon Nov 10 14:40:44 PST 2008
2008/11/10, John Baldwin <jhb at freebsd.org>:
> On Saturday 08 November 2008 11:53:53 am Attilio Rao wrote:
> > 2008/11/8, David Schultz <das at freebsd.org>:
> > > On Sat, Nov 08, 2008, Attilio Rao wrote:
> > > > Definitively, I'm not sure we need this.
> > > > We alredy have memory barriers you could exploit which just require a
> > > > "dummy" object.
> > > >
> > > > For example you could do:
> > > > flowtable_pcpu_unlock(struct flowtable *table, uint32_t hash)
> > > > {
> > > >
> > > > (void)atomic_load_acq_ptr(&dummy);
> > > > ...
> > >
> > >
> > > Memory barriers are cheaper than atomic ops.
> >
> > But this is an atomic op too.
> >
> > > Furthermore, there's different types of memory barriers
> > > (store/store, load/store, etc.), not just a generic mb(). Some
> > > architectures like sparc64 define all four, but only actually
> > > implement the varieties that are useful in improving performance.
> > > Take a look at what Solaris has here.
> > >
> > > I'm skeptical of trying to play clever tricks with these things
> > > outside of the code that implements synchronization
> > > primitives. Memory ordering is very hard to reason about, and we
> > > already have a lot of code, e.g., in libthr, that isn't correct
> > > under weak memory ordering. Moreover, the compiler can reorder
> > > loads and stores, and that just adds a whole new level of pain.
> >
> > _acq prefix is intended to not let reordering happening really.
> > man 9 atomic can explain how the acq and rel memory barriers work.
>
>
> _acq is not a full barrier, it's more of an 'lfence'. The mb() here is doing
> more of a _rel barrier ('sfence', etc.).
Sure but the comment is still valid.
I don't see the point of such things when you can implement barriers
trough our atomic_* stuff.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
More information about the svn-src-user
mailing list