svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net

David Schultz das at FreeBSD.ORG
Sat Nov 8 08:50:35 PST 2008


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.

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.


More information about the svn-src-user mailing list