Philip Martin wrote on Mon, Mar 05, 2012 at 11:21:21 +0000: > Daniel Shahaf <danie...@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