[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and set it to 5 at device_remove

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check 
backend state and set it to 5 at device_remove"):
> Also I've found myself using a lot a construction like the following:
> - check xenstore path
> - If path value is different than x
> - Set up a watch
> - Wait for events.
> And I'm afraid it's not concurrent safe, since someone can perform a
> bunch of xenstore changes in the space between setting the watch, and
> wait for events. The watcher will only get notified of the last
> xenstore change, but not all changes that happened between.

xenstore is not a message-passing protocol in that way.  There is no
way to be sure that you see all the intermediate values of a
particular xenstore node.  The required approach is for the protocol
not to care about intermediate values, or for the "sender" to
coordinate with the "receiver" somehow.

If all you mean is that you worry about the path changing between the
first read and the setting up of the watch, then you're fine: every
watch is guaranteed to fire once right after you set it up, so your
watch handler function will definitely read the path again and you
won't sit waiting for an event that never comes.


Xen-devel mailing list



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