[libvirt] [PATCH 1/14] Adding recursive locks

[Daniel P. Berrange]

On Thu, Mar 18, 2010 at 11:04:17AM -0600, Eric Blake wrote:
> On 03/18/2010 10:51 AM, Daniel P. Berrange wrote:
> > On Thu, Mar 18, 2010 at 10:41:58AM -0600, Eric Blake wrote:
> >> On 03/18/2010 09:15 AM, Stefan Berger wrote:
> >>> This patch adds recursive locks necessary due to the processing of
> >>> network filter XML that can reference other network filters, including
> >>> references that cause looks. Loops in the XML are prevented but their
> >>> detection requires recursive locks.
> >>
> >> ACK.  I had to double-check MSDN to make sure that threads-win32 already
> >> creates recursive mutex by default.
> > 
> > I don't supposed you read if its possible to make it non-recursive, since
> > the orginal impl is supposed to be non-recursive !
> 
> Unfortunately, I don't see a way:
> 
> http://msdn.microsoft.com/en-us/library/ms684266%28VS.85%29.aspx
> 
> states:
> 
> After a thread obtains ownership of a mutex, it can specify the same
> mutex in repeated calls to the wait-functions without blocking its
> execution. This prevents a thread from deadlocking itself while waiting
> for a mutex that it already owns. To release its ownership under such
> circumstances, the thread must call ReleaseMutex once for each time that
> the mutex satisfied the conditions of a wait function.
> 
> with no mention of any way to parameterize it to be non-recursive.
> 
> But what does a true non-recursive mutex buy you?  The only difference
> between recursive and true non-recursive is whether you declare that an
> attempt to relock a mutex that you already own is a fatal deadlock
> error, rather than incrementing a counter for matching unlocks.  It's
> just that non-recursive mutexes typically have faster implementations.
> 
> For that matter, do we even need the distinction?  Maybe ALL our code
> should be using recursive mutexes by default, by changing virMutexInit
> to be recursive no matter what, and not worry about introducing
> virMutexInitRecursive. 

Having the mutex be non-recursive is a good thing, because more or less
any code which causes recursion with our thread locking rules is broken
by design and/or impl. Thus any deadlocks we encounter from non-recursive 
mutexes are highlighting bugs we'd not otherwise see.

I'm not even convinced that this network filter stuff should need to
have recursive mutexes, but we can leave that to address another day

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|