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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xensource.com/xen-devel