Daniel P. Berrange wrote: > On Wed, Oct 01, 2008 at 08:41:19AM +0530, Balbir Singh wrote: >> Dan Smith wrote: >>> DB> At the same time having the controllers mounted is mandatory for >>> DB> libvirt to work and asking the admin to set things up manually >>> DB> also sucks. So perhaps we'll need to mount them automatically, but >>> DB> make this behaviuour configurable in some way, so admin can >>> DB> override it >>> >>> Perhaps we can: >>> >>> - Have a list of controllers we use (memory and devices so far) >>> - Create each group in all mounts required to satisfy our necessary >>> controllers >>> - Select the appropriate mount when setting a cont.key value >>> >> I am not sure how libvirt provides thread safety, but I did not see any explicit >> coding for that? > > The thread safety model for libvirt has two levels > > - A single virConnectPtr object must only be used by one thread. > If you have multiple threads, you must provide each with its > own conenct object > > - Within a stateless driver (Xen, OpenVZ, Test), there is no shared > state between virConnectPtr objects, so there are no thread issues > in this respect > > - With a stateful driver, the libvirtd daemon ensures that only a > single thread is active at once, so against there are no thread > issues there either. > > Now, in a short while I will be making the daemon fully-multithreaded. When > this happens, the stateful drivers will be required to maintain mutexes for > locking. The locking model wil have 2 levels, one lock over the driver as > a whole. This is held only while acquiring a lock against the object being > modified (eg the virtual domain object). > > Each virtual domain, lives in one cgroup, so there is a single virCGroup > object associated with each domain. the virCGroup object state is seflf > contained, so independant virCGroup objects can be accessed concurrently > from multiple threads, without any threads safety issues. Thanks, that was quite insightful. -- Balbir -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list