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

Ben Pfaff blp at nicira.com
Wed Mar 17 21:19:08 UTC 2010


On Wed, Mar 17, 2010 at 03:13:47PM -0400, Jesse Gross wrote:
> 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.

Awesome, thank you.  I will push this out soon.




More information about the dev mailing list