Hi!
On 14:03 Thu 04 Apr , Arlie Stephens wrote:
...
> On Apr 04 2013, [email protected] 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
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
