On Fri, Aug 29, 2014 at 12:50:24PM -0700, Jarno Rajahalme wrote: > > On Aug 29, 2014, at 9:36 AM, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > > > > On Aug 28, 2014, at 9:32 AM, Ben Pfaff <b...@nicira.com> wrote: > > > >> On Fri, Aug 22, 2014 at 01:58:17PM -0700, Jarno Rajahalme wrote: > >>> barrier->count is used as a simple counter and is not expected the > >>> synchronize the state of any other variable, so we can use atomic_count, > >>> which uses relaxed atomics. > >>> > >>> Ditto for the 'next_id' within ovsthread_wrapper(). > >>> > >>> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > >> > >> I would have thought that ovs_barrier_block() would include a fairly > >> strong barrier--at least an acquire-release barrier?--but it doesn't > >> seem to necessarily include one at all now. > > > > Yes, it would seem reasonable to expect that the effects of all > > participating threads would be visible on return from ovs_barrier_block(). > > Even after this change the seq_read() does that (due to ovs_mutex_lock() > > and ovs_mutex_unlock(), which have acquire and release semantics, > > respectively). However, seq_read() could be implemented without using a > > mutex, so it would be better to not rely on it. > > > > I looked into this a bit more and I now think seq makes no sense > without acquire-release semantics (which it already implements), so > I plan to document it and then rely on it. Let?s see what you think.
I'm happy with that approach. I haven't looked at the revised patches yet. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
