Eric Dumazet wrote:
Nick Piggin a écrit :
Again, lock / unlock operations require acquire / release
consistency. This is a
memory ordering operation. It is not equivalent to smp_mb, though.
This thread just show how difficult it is to have consistent use of
all this stuff in all kernel. Maybe it is just me ? Should I work on
IA64 to have a chance to learn ?
No need, just don't go thinking that mutex_unlock implies smp_mb.
spin_unlock has never implied an smp_rmb on i386.
For example, Documentation/atomic_ops.txt comments about
atomic_inc_return() and atomic_dec_return() seems in contradiction
with itself.
--------------------------
Unlike the above routines, it is required that explicit memory
barriers are performed before and after the operation. It must be
done such that all memory operations before and after the atomic
operation calls are strongly ordered with respect to the atomic
operation itself.
-------------------------
When I read this, I understand we (the user of such functions) need to
add smp_mb(). (That is, those functions wont do it themselves)
This is written from the point of view of the _implementor_. I agree it
is a bit
confusing, but does the example below clear it up?
Then following text is :
----------------------------
For example, it should behave as if a smp_mb() call existed both
before and after the atomic operation.
--------------------------
Now I understand the reverse.
Now you understand correctly ;)
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
