[ovs-dev] [thread-safety 08/11] mac-learning: Make the mac-learning module thread safe.

Ben Pfaff blp at nicira.com
Thu Aug 1 18:33:48 UTC 2013


On Tue, Jul 30, 2013 at 02:37:38PM -0700, Ethan Jackson wrote:
> > Why does the client do the locking?
> 
> In a couple of places we iterate over each mac_entry by directly
> accessing its LRU node.  I tried hiding the locking internally, but
> believe it or not this turned out to be cleaner.  If we could hide the
> iteration inside the mac-learning module that would be ideal of
> course.  It's outside the scope of what I'm trying to do here though.

OK.

I actually like data structures that are locked externally, when it is
possible, because it gives additional flexibility.  You can, for
example, implement multi-object transactions without additional cost,
or you can leave out the locking entirely if it isn't needed.  In the
past, I've ordinarily seen this done by putting the lock itself
outside the data structure, since for a data structure with multiple
purposes you might want to lock it differently, or not at all.  For
example, lswitch is only used from the single threaded ovs-controller
program, so it doesn't really need any lock at all.  OTOH, it will be
harder to take advantage of the clang annotations if only some users
lock, and there's no real penalty to ovs-controller.

Anyway,
Acked-by: Ben Pfaff <blp at nicira.com>



More information about the dev mailing list