> -----Original Message-----
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: donderdag 13 februari 2014 23:05
> To: comm...@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().
Bert
