[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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.