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