[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1296604 - in /subversion/trunk/subversion/libsvn_fs_fs: caching.c fs.h fs_fs.c

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Mon, 5 Mar 2012 13:29:42 +0200

Philip Martin wrote on Mon, Mar 05, 2012 at 11:21:21 +0000:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> >> What about atomic revprop changes? I don't see what ensures that the
> >> old value read by change_rev_prop_body is the most up-to-date value.
> >>
> >
> > ffd->revprop_generation is used as part of the cache key, the file is
> > written before the write-lock is released and read again as soon as the
> > write-lock is taken. Do you see a problem?
>
> I'm worried about the case where the FS passed to
> svn_fs_fs__change_rev_prop has a cache that is already populated. The
> values in the cache might be out-of-date because some other thread with
> another FS has written newer values. It looks like change_rev_prop_body
> will examine the out-of-date cached value when doing the "atomic"
> update.

The values will be in a cache under a key of the form (N,g), but the
cache lookup will use a key (N,g'), where $g' > g$, and will therefore
fail. Here, $N$ is a revnum and $g$ is a revprop generation.

>
> --
> Philip
Received on 2012-03-05 12:30:26 CET

This is an archived mail posted to the Subversion Dev mailing list.