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

> -----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().

        Bert
Received on 2014-02-14 00:53:34 CET