[ovs-dev] [PATCH 06/18] lib/ovs-thread: Use atomic_count.

Ben Pfaff blp at nicira.com
Fri Aug 29 20:08:44 UTC 2014


On Fri, Aug 29, 2014 at 12:50:24PM -0700, Jarno Rajahalme wrote:
> 
> On Aug 29, 2014, at 9:36 AM, Jarno Rajahalme <jrajahalme at nicira.com> wrote:
> 
> > 
> > On Aug 28, 2014, at 9:32 AM, Ben Pfaff <blp at 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 <jrajahalme at 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.



More information about the dev mailing list