Hi! On 14:03 Thu 04 Apr , Arlie Stephens wrote: ... > On Apr 04 2013, michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
