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

[Attilio Rao]

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.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein