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

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: stefan2@apache.org [mailto:stefan2@apache.org]
> Sent: donderdag 13 februari 2014 23:05
> To: commits@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