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

Re: svn commit: r1567996 - /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 13 Feb 2014 20:40:15 +0100

On Thu, Feb 13, 2014 at 7:55 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:

> On 13 February 2014 22:24, <stefan2_at_apache.org> wrote:
> > Author: stefan2
> > Date: Thu Feb 13 18:24:17 2014
> > New Revision: 1567996
> >
> > URL: http://svn.apache.org/r1567996
>

> > +/* Count a hit in ENTRY within CACHE.
> > + */
> > +static void
> > +increment_hit_counters(svn_membuffer_t *cache, entry_t *entry)
> > +{
> > + /* To minimize the memory footprint of the cache index, we limit local
> > + * hit counters to 32 bits. These may overflow and we must make sure
> that
> > + * the global sums are still (roughly due to races) the sum of all
> local
> > + * counters. */
> > + if (++entry->hit_count == 0)
> > + cache->hit_count -= APR_UINT32_MAX;
> > + else
> > + cache->hit_count++;
> > +
> As far I understand this counters are updated from several threads
> without mutex?

That is correct.

> In that case we have to use atomic functions to
> increment them, otherwise we may skip hit_count == 0 in some cases.
>

No. Assuming that the system does not split 32 bit read
nor write operations, one (or more) of the threads must
increment the value to APR_UINT32_MAX+1==0. No
thread will accidentally add by 2 (or more) missing the
actual overflow.

-- Stefan^2.
Received on 2014-02-13 20:40:48 CET

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.