Hi! On 14:03 Thu 04 Apr , Arlie Stephens wrote: ...
On Apr 04 2013, michi1@michaelblizek.twilightparadox.com wrote: ...
On 19:08 Wed 03 Apr , Arlie Stephens wrote: ...
fix __list_add() so it updates pointers in the new entry before updating pointers in its neighbours,
IMHO, this is like asking for trouble. Somebody else might change the order in the future without knowing it might break your stuff. Also, if you have bad luck, somebody else might already depend on the current order without you knowing.
It's notable that __list_add_rcu(), from rculist.h has the order the way I want it, even in our elderly kernel version.
You should at least do atomic_read()+atomic_set(). RCU is exactly that plus a mechanism to free memory after all readers have finished.
Now I'm confused. It seems to me that part of RCU's contribution is use of barrier instructions (compiler and run-time) at appropriate points. Are you saying that atomic_read() and atomic_set() have implicit barriers?
You are right, it seems like atomic ops do not imply barriers: Documentation/atomic_ops.txt -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com