[libvirt] [PATCH 03/21] Convert QEMU driver mutex into a rwlock

Daniel P. Berrange berrange at redhat.com
Wed Oct 28 17:52:17 UTC 2009


On Wed, Oct 28, 2009 at 05:24:00PM +0100, Daniel Veillard wrote:
> On Fri, Oct 23, 2009 at 02:05:32PM +0100, Daniel P. Berrange wrote:
> > A number of driver API methods which acquire the driver mutex
> > only ever used the driver object in a read-only fashion. All
> > these uses are converted to call qemuDriverLockRO() allowing
> > for greater concurrency.
> > 
> > * src/qemu/qemu_conf.h: s/Mutex/RWLock/
> > * src/qemu/qemu_driver.c: Add a qemuDriverLockRO() method and use
> >   it anywhere that doesn't require a write lock on the driver
> 
>   Hum, I still wonder about erro handling strategies there, for example
> even taking a read lock may fail not because of a programing error 
> because there is already too many read lock taken.
> 
> [...]
> > @@ -6834,6 +6846,8 @@ cleanup:
> >  
> >      if (vm)
> >          virDomainObjUnlock(vm);
> > +    qemuDriverUnlock(driver);
> > +    qemuDriverLock(driver);
> >      if (event)
> >          qemuDomainEventQueue(driver, event);
> >      qemuDriverUnlock(driver);
> 
>   Huh ??? really ? we need a way to allow other threads to get in ?
> Maybe a tiny wait here would allow a rescheduling especially if on a
> single processor.

This is a merge error.

>   But otherwise this looks like a fairly automatic conversion so should
> go in with 02/21 when ready, ACK

I'm withdrawing this patch, and the one implementing  RWLock. I believe I
have a more effective way to deal with concurrency. See the mail I just
sent out....

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




More information about the libvir-list mailing list