[ovs-dev] [PATCH 4/8] ovsdb: Introduce for_each_txn_row() iterator function for transactions.

Jesse Gross jesse at nicira.com
Wed Mar 17 19:13:47 UTC 2010


On Wed, Mar 17, 2010 at 2:34 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Wed, Mar 17, 2010 at 02:02:24PM -0400, Jesse Gross wrote:
> > On Mon, Mar 15, 2010 at 6:42 PM, Ben Pfaff <blp at nicira.com> wrote:
> > >
> > > +
> > > +/* Used by for_each_txn_row() to track tables and rows that have been
> > > + * processed.  */
> > > +static unsigned int serial;
> >
> > This static variable and the new members in the two structs that are used
> > for iteration feel a little weird to me.  I don't think that it will
> cause a
> > problem since this is all single threaded code but it still doesn't
> really
> > seem right.  I don't know this code well enough to say what might be
> right
> > though.
>
> It will work even if we thread it, as long as a given database is being
> iterated in only a single thread at a time and we slap a mutex around
> fetch-and-increment of "serial".  That seems reasonable to me.
>

I was thinking of iterating from multiple threads.  However, given that this
is used for things like committing transactions, which would need to have a
lock anyways, it is not likely to be a problem.  In any case, since it is
not multithreaded it is a moot point.


>
> The problem being solved here is iterating through a data structure that
> may be changing, trying to visit every element in it exactly once even
> in the face of insertions and deletions.  A serial number protocol is
> the best solution that I know, even though (as you say) it has a certain
> crummy esthetic quality.  If you have a better solution to suggest, then
> I am all ears (seriously; I'd like to learn about better solutions).
>

I agree that using serial numbers is the best generic way to do it.  Like I
said, now that I think about the situations where it would be used it
doesn't seem so bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100317/fdc313d7/attachment-0003.html>


More information about the dev mailing list