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

RE: svn commit: r1568062 - /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 14 Feb 2014 00:52:52 +0100

> -----Original Message-----
> From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> Sent: donderdag 13 februari 2014 23:05
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1568062 -
> /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
> Author: stefan2
> Date: Thu Feb 13 22:05:26 2014
> New Revision: 1568062
> URL: http://svn.apache.org/r1568062
> Log:
> Membuffer cache hit counter update done right: introduce a separate
> per-segment mutex for counter updates. Since the critical section
> is very tight, there is little actual lock contention and the sync.
> overhead is virtually non-existent (tested with 100 concurrent threads
> on one and two-socket systems).

Why do you create a mutex when a simple atomic increment as suggested earlier in this thread would work just fine?

An atomic increment is 100% implemented in most CPUs with a single operation while the callback infrastructure you now use for the call, can't be inlined... and even involves a few DLLs in our usual shared library setup and in some cases even involves kernel operations. The number of system mutexes might even be limited in some implementations.

I think you could replace most of this patch with a few calls to apr_atomic_inc32().

Received on 2014-02-14 00:53:34 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.