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

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

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Sun, 29 Apr 2012 14:15:19 +0200

Am 28.04.2012 16:41, schrieb Daniel Shahaf:
> stefan2_at_apache.org wrote on Sat, Apr 28, 2012 at 13:48:00 -0000:
>> Author: stefan2
>> Date: Sat Apr 28 13:48:00 2012
>> New Revision: 1331763
>>
>> URL: http://svn.apache.org/viewvc?rev=1331763&view=rev
>> Log:
>> The lifetime of the shared-memory based named atomics used for
>> revprop generation communication and storage may be as short as
>> that of the svn_fs_t. Cached revprops may live as long as the process,
>> though. Therefore, we must store the revprop generation on disk
>> and re-read it when we encounter un-initialized (having only the
>> default value of 0) the named atomics.
>>
>> Please note that the revprop generation file is optional an may be
>> removed or remain unchanged when being used with older servers.
>> Therefore, no format bump is necessary.
> I'm lost. The cache lives as long as the process, the generation as
> long as the svn_fs_t, therefore you cache the generation on-disk? In
> a file whose name is _not_ keyed on the process (or even the machine)?
>
> This sounds wrong. (For example, if two processes on the same machine
> both swap out their generation to a file, and then read it back, one of
> them will get the wrong value.) Isn't the right solution to store the
> generation in memory of the same lifetime as the cache itself?
>
The problem is that there is globally available file name
to back the SHM implementation on OSes that need it.
We can only assume write access to some file within the
respective repositories.

Because a given server process may access thousands of
repositories during its lifetime, keeping the SHM data
alive for all of them is not an option, too.

So, we store the new revprop generation as part of each
setrevprop call, i.e. this write will be serialized and the
write order be kept by the repository write lock.

The only racy situation occurs when the data is being read
again but the first one to finish that procedure is guaranteed
to be the only one that initializes the SHM data. Since even
writers will first go through that initialization phase, they
will never operate on stale data.

-- Stefan^2.
Received on 2012-04-29 20:23:05 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.