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.
But otherwise this looks like a fairly automatic conversion so should
go in with 02/21 when ready, ACK
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/