Rusty Russell wrote:
>
> In message <39783869.382726BA@colorfullife.com> you write:
> > I'm interested in the ordering of atomic_xy and bit operations: I heard
> > that they must be full memory barriers, but at least the ia64 port only
> > uses a partial memory barrier.
>
> >From kernel-locking.tmpl:
> Any atomic operation is defined to act as a memory barrier
> (ie. as per the <function>mb()</function> macro).
>
I read that document, but the actual source doesn't match this
definition:
Just check atomic_read() and atomic_set(): they don't act as memory
barrier's, not even on i386. s390 is the only architecture that contains
a memory barrier within atomic_read().
> If people are building locks with the test_* bitops and atomic_*_test
> functions, we only need a partial barrier requirement as spin_lock().
> This implies non-test atomic ops must have same barrier properties as
> spin_unlock().
>
Or check the simple test_bit() macro: it isn't a memory barrier on i386.
> Alan? Does it make sense to weaken this restriction?
> Rusty.
IMHO we should define the restriction, and then modify <asm-*/atomic.h>
and <asm-*/bitops.h> accordingly.
And an unconditional memory barrier in every atomic operation would be
very expensive.
-- Manfred- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:26 EST