On Mon, Feb 6, 2012 at 7:33 PM, Jesse Gross <[email protected]> wrote: > On Mon, Feb 6, 2012 at 6:50 PM, Pravin Shelar <[email protected]> wrote: >> On Mon, Feb 6, 2012 at 3:25 PM, Jesse Gross <[email protected]> wrote: >>> I think the biggest problem here is that there's no clear >>> documentation on what guarantees we're providing. There's two >>> possibilities that I see: that the flex array data structure itself is >>> safe to read as it is being expanded on a different CPU or that both >>> the data structure and the data being written are safe. For our >>> purposes we only care about the former because the data are pointers >>> and we can initialize it to zero so everything is atomic. The latter >>> is impossible to enforce for arbitrary data with the way that flex >>> arrays are set up because after a part is allocated there's no pointer >>> write to create an atomic switch with which we can enforce ordering. >>> It looks like the RCU primitives that you used protect the structure >>> itself and the open coded components are trying to protect the data. >>> >> ok, It will not work when non pointer data is stored in flex_array. I >> will move mem barrier to caller. > > Yes, if this is enforcing locking for the caller then it needs to be > done by the caller. However, since this is using RCU it needs to use > the RCU API without exception. If that's not possible then the > flex_array API needs to be changed (I think a pointer model is better > than the current one based on copying).
ok, I will change flex array to store pointers only. That way we can use RCU APIs without exception. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
