[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 16/18] libxl: introduce libxl_userdata_unlink
On Wed, 2014-09-03 at 15:10 +0100, Wei Liu wrote: > For the record, here is summary of the face-2-face discussion Ian and I > had. Thanks for summarising! > The lock proposed in patch 2 should be renamed to "domain-data-lock" to Better "domain-userdata-lock" I think, to make it completely clear.. > avoid making the false impression that it's related to libxl-json data. > > For any specific application, it should hold a lock to protect its own > userdata if it cares, to protect against r-m-w by other threads. > > With the introduction of libxl-json data, libxl becomes an application > of libxl itself, in the sense that libxl now does r-m-w to libxl-json > data internally. Hence it needs a lock (LockA). > > The said lock, proposed in patch 2, is used to lock all types of user > data related to a specified domain. It protects userdata against domain > destruction (LockB). > > I reused the lock in patch 2 as the application data lock for libxl-json > data. The lock serves two purposes: > 1. to protect against r-m-w to libxl-json data > 2. to protect against domain destruction > > This double-duty lock is what confuses most. In theory LockA and LockB > can be different locks but there isn't much benefit in doing so in terms > of protecting libxl-json data. > > In general, locking hierarchy should be > application userdata lock (if any) > ---- (inside libxl) > libxl domain data lock > ... > libxl domain data unlock > ---- > application userdata unlock > > In the case of protecting libxl-json data, the application userdata lock > is the same one as libxl domain data lock, so the locking hierarchy is > preserved. > > Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |