On Mon, Nov 11, 2013 at 10:40:11AM +0000, Daniel P. Berrange wrote: > On Fri, Nov 08, 2013 at 08:54:39AM +0100, Michal Privoznik wrote: > > On 08.11.2013 06:27, Daniel P. Berrange wrote: > > > On Thu, Nov 07, 2013 at 11:39:27AM +0100, Michal Privoznik wrote: > > >> Similarly to VIR_FREE() we can set the pointer passed to virObjectUnref > > >> to NULL in case of disposing the object. However, to avoid overwriting > > >> nearly thousands line of code, the virObjectUnref is turned into a macro > > >> which passes the address of pointer and calls virObjectUnrefInternal > > >> (the modified version of original virObjectUnref). > > > > > > I have to say I'm not really liking this, and your impl is not race > > > free since you're not atomically updating the point. > > > > > > Daniel > > > > > > > > > I don't think I follow you there. AFAIU, the whole 'if' body is executed > > exactly once iff obj->refs is zero after decrement. And I don't see how > > can I possibly race with others. > > > > If two threads calls virObjectUnref on the very same object with > > refcount = 1, do you expect them both to have the *ptr = NULL? > > The first thread decrements refcount, so it hits zero. Now a short time > later it sets *obj = NULL, but at the same time another thread is running > virObjectUnref(). It will check *obj != NULL, which races with setting > *obj = NULL. > IIUC, the only problem here is our invalid usage, two threads both working with one object that has refcount = 1, right? The race can happen either way if you are in such kind of situation (and have VIR_FREE() after virObjectUnref()). Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list