On 2 August 2014 13:02, Bert Huijben <b...@qqmail.nl> wrote: > Hi, > > With this mail I would like to ping the original problem with the second > patch I send to the list. This patch doesn't have the likely original > problems of potentially changing the lock behavior to a spin lock, but > provides all the performance improvements anyway. > > It just replaces the Windows inter-proces mutex in the apr code with the > already existing apr-mutex implementation, which is usually implemented as > the far more efficient Windows in-process Critical section. > > This makes the implementation 10* to 140* times more efficient on Windows > and more similar to the performance on other platforms. A performance fix > like this is critical for Subversion, or we would have to implement our own > r/w locking implementation for our caching infrastructure. > Hi Bert,
Comments on your patch: 1. It seems behavior of apr_thread_rwlock_create() functions changes a bit: code in trunk intializes output *rwlock pointer to NULL in case of error, while your patch returns pointer to partially initialized object. It seems that apr_thread_rwlock_create() doesn't have API promise to initalize output to NULL, but I think it's better to leave current behavior. 2. The apr_thread_rwlock_unlock() currently uses checked mutex behavior for its logic. This is possible reason why current rwlock implementation uses OS mutexes instead of cirtical sections. I don't see problem with proposed change though. -- Ivan Zhakov
