Daniel P. Berrange wrote:
The current test driver keeps all its state in memory and is
not thread safe. Since background jobs will need to access
state from a thread periodically we need to make the test
driver thread safe. This is done with 2 levels of locking
- A global driver lock.
- A per-connection lock
Before taking the per-connection lock, the global driver lock
must be acquired. The driver lock can be released the moment
the connection lock is acquired. The connection lock must be
held for the duration of all driver methods which are accessing
the 'struct testConn' or 'struct testDom' or 'struct testNet'
data.
To keep this reasonably unobtrusive, the GET_CONNECT, and
GET_DOMAIN / GET_NETWORK macros have been altered to do the
neccessary lock acquisition. The RELEASE_DOMAIN and RELEASE_NETWORL
macros are new, and must be used prior to returning from any
driver method so that mutex are released.
This is a fairly coarse level of locking, but effective enough
for the test driver which is not performance critical - merely
safety critical.
This model should apply reasonably safely to the QEMU driver
too, though we may wish to make it finer grained.
Sensible. Maybe add some artifically slow functions to the test driver
as well so that we can test job control?
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903