[libvirt] [PATCH 1/2] virObjectUnref: Set pointer to NULL on dispose

[Martin Kletzander]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131111/0978f9a9/attachment-0001.sig>