[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: Fri, 14 Feb 2014 20:32:48 +0100

On Fri, Feb 14, 2014 at 1:01 AM, Bert Huijben <bert_at_qqmail.nl> wrote:

> Sorry for the big number of small replies...
>
>
>
> And the 'cache->total_reads++;' calls?
>
>
>
> Doesn't that need a similar handling?
>
>
>
> Bert
>
>
>
> *From:* Bert Huijben [mailto:bert_at_qqmail.nl]
> *Sent:* vrijdag 14 februari 2014 00:58
> *To:* 'Stefan Fuhrmann'; 'Ivan Zhakov'
>
> *Cc:* 'Subversion Development'; 'Stefan Fuhrman'
> *Subject:* RE: svn commit: r1567996 -
> /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
>
>
>
> [[
>
> Well, you were wrong on your initial point ("missing zero crossing").
>
> And you have been wrong on the "use the atomic functions" bit because
> they don't cover 64 bit integers. The only available option is a critical
> section (svn_mutex__t).
>
> ]]
>
>
>
> The 64 bit integer is for statistics only...
>
>
>
> If you just drop that one (that you only used for debugging your code...
> There is no single read of that variable) the rest can be an atomic
> increment.
>

entry->hit_count is 32 bits and atomic increment would be possible.
cache->hit_count is 64 bits for which we don't have portable atomic
operations.

cache->total_xzy are 64 bits but are for dev statistics only and not an
input
for any logic. When they happen to be updated in a synchronized environment,
that's fine, if not it's o.k., too. There is no need to write 3 or 4 extra
serializable
"increment" functions.

-- Stefan^2.
Received on 2014-02-14 20:33:20 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.