--- Satyam Sharma <[email protected]> wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:
>
> > Satyam Sharma wrote:
> > > Consider this (the above two functions exist
> only for clear_bit(),
> > > the atomic variant, as you already know), the
> _only_ memory reference
> > > we care about is that of the address of the
> passed bit-string:
> >
> > No. Memory barriers explicitly extend to all
> memory references.
>
> [ Compiler barrier, you mean, that's not true of CPU
> barriers. ]
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
> In any case, I know that, obviously. I asked "why"
> not "what" :-) i.e.
> why should we care about other addresses / why do we
> want to extend
> the compiler barrier to all memory references -- but
> Jeremy seems to
> have answered that ...
Obviously because we want some kind of ordering
guarantee at a given point. All the CPU barriers
in the world are useless if the compiler can reorder
access over them.
> > Repeating what has been said before: A CPU memory
> barrier is not a
> > compiler barrier or vice versa. Seeing as we are
> talking about
> > the compiler barrier, it is irrelevant as to
> whether or not the
> > assembly includes a CPU barrier.
>
> I think it is quite relevant, in fact. From
> Documentation/atomic_ops.txt,
> smp_mb__{before,after}_clear_bit(), as the name
> itself suggests, must
> be _CPU barriers_ for those arch's that don't have
> an implicit
> _CPU barrier_ in the clear_bit() itself [ which i386
> does have already ].
>
> As for a compiler barrier, the asm there already
> guarantees the compiler
> will not optimize references to _that_ address
One or both of us still fails to understand the other.
bit_spin_lock(LOCK_NR, &word);
var++;
/* this is bit_spin_unlock(LOCK_NR, &word); */
smp_mb__before_clear_bit();
clear_bit(LOCK_NR, &word);
Are you saying that it is OK for the store to var to
be reordered below the clear_bit? If not, what are you
saying?
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
