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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list