Re: svn commit: r1615349 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_subr/mutex.c
On 11 August 2014 20:29, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> On Mon, Aug 4, 2014 at 4:23 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On 4 August 2014 17:48, Branko Čibej <brane_at_wandisco.com> wrote:
>> > On 04.08.2014 15:22, Ivan Zhakov wrote:
>> > On 2 August 2014 23:13, <stefan2_at_apache.org> wrote:
>> > @@ -195,7 +206,9 @@ svn_mutex__unlock(svn_mutex__t *mutex,
>> > #else
>> > /* Update lock counter. */
>> > if (mutex->checked)
>> > - --mutex->count;
>> > + if (--mutex->count)
>> > + return svn_error_create(SVN_ERR_INVALID_UNLOCK, NULL,
>> > + _("Tried to release a non-locked
>> > mutex"));
>> > 1. Why you are using non-atomic decrement here while we're using
>> > casptr() for mutex->owner?
>> > This bit of code is only used when APR does *not* support threads, IIRC.
>> > So
>> > atomic insns are overkill.
>> Ok. It was not clear from unidiff and log message that change is about
>> !APR_HAS_THREADS code.
>> > 2. You're leaving mutex object in invalid state on attempt to release
>> > non-locked mutex.
>> > That's been fixed.
>> OK. Another question: why this situation not considered as malfunction?
> Because it can be triggered through (erroneous) use of our FS API.
> For instance: svn_fs_freeze(modify_stuff) will deadlock in 1.8 and
> give a "recursive lock" error in 1.9 Returning a malfunction would be
> misleading as there is nothing wrong with the SVN libs.
This is reason for check that lock is already obtained by the same
thread, while I'm asking why attempt to release non-locked mutex is
not considered as malfunction?
Received on 2014-08-12 21:35:27 CEST
This is an archived mail posted to the Subversion Dev