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 <b...@nicira.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
