Re: [Libevent-users] libevent custom thread library: Recursive mutexes and wait conditions

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Mon, Jun 25, 2012 at 5:21 PM, Julian Bui <julianbui@xxxxxxxxx> wrote:
> Hello libevent,
>
> I am writing to see if I could get clarification on wait conditions and
> their use with recursive locks.
>
> My first issue is understanding how a custom evthread_lock is supposed to be
> implemented.  evthread_lock_callbacks::supported_locktypes() documentations
> says "Note that RECURSIVE locks are currently mandatory, and READWRITE locks
> are not currently used."  So I debugged the alloc method of my custom lock
> and noticed that only a locktype of 0 was being used which I assume is
> non-recursive.  At first, this description made it sound like only recursive
> locks are requested by the library, but that's not the case.  In what cases
> will the libevent library try to allocate a recursive lock?

Right now, nearly all the locks Libevent allocates are recursive.
Probably, some of them could be changed not to be recursive.   That
would be a neat project to work on. The highest value lock here would
be the th_base_lock lock in struct event_base.

> As a side note, I would suggest that there be like a NONRECURSIVE flag, so
> that 0 has a clear definition.

Hm; I'm not sure that makes so much sense.  0 is the absence of flags,
not a flag itself.

> Secondly, I'm not sure what the behavior of evthread_condition is since
> using recursive locks and wait conditions has always been tricky
> (see http://en.wikipedia.org/wiki/Reentrant_mutex paragraph starting with "A
> big form of criticism on recursive mutexes is that when used in combination
> with condition variables").  And the custom thread/locking library that I
> wish to use doesn't even support wait conditions with recursive mutexes.  I
> use QtWaitCondition and it doesn't even really even support waiting on a
> recursive mutex ("If mutex is a recursive mutex, this function returns
> immediately.", http://doc.qt.nokia.com/4.7-snapshot/qwaitcondition.html#wait).
>  I'm not sure how how I should be implementing this and what it means for
> libevent.  If libevent tries to wait on a recursive mutex, should it
> actually wait or should it return immediately?  The expected behavior should
> probably be documented.  This is problematic since the library I use doesn't
> support this.  Would libevent even run into this situation?

When I added locking to Libevent, I wasn't aware of these restrictions
in Qt's condition code. Right now, Libevent uses its conditions only
with the pthreads recursive and windows CRITICAL_SECTION
implementations of locking, which don't (or don't appear to?) have
conflicts of this kind.

My first thought here is that the easiest response would be to
refactor stuff in Libevent 2.1 so that th_base_lock is no longer
recursive.

yrs,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.