Date: Sat, 8 Nov 2008 17:53:53 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Attilio Rao" <attilio@freebsd.org>, "Kip Macy" <kmacy@freebsd.org>, src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net Message-ID: <3bbf2fe10811080853j3ebf5b2em29ebdd2a7187ff67@mail.gmail.com> In-Reply-To: <20081108163006.GA5256@zim.MIT.EDU> References: <200811080202.mA822D0W098283@svn.freebsd.org> <3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com> <20081108163006.GA5256@zim.MIT.EDU>
index | next in thread | previous in thread | raw e-mail
2008/11/8, David Schultz <das@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.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10811080853j3ebf5b2em29ebdd2a7187ff67>