On Thu, 24 Sep 2009 14:17:50 +0100
Alan Maguire <Alan.Maguire at Sun.COM> wrote:
> Michael Hunter wrote:
> > webrev at file:///net/coupe.eng/builds/mph/nwam1_cr_fixes/webrev/index.html
> >
> > Issue is that we would finalize object not holding lock for object
> > allow for another object to grab reference. Change finialization
> > function so it expects to be holding lock when it is called and then
> > only release lock after we've removed the object from the store.
> >
> >
> Hmm, what happens if after we've locked the object (on
> the way to destroying it) another thread attempts to
> acquire the object lock via nwamd_object_find() and
> is left spinning at nwamd_object_lock(). Then the thread
> disposing of the object will then call nwamd_object_unlock_fini(),
> and the mutex the waiting thread is waiting on is deallocated. How
> will that waiting thread behave? Will pthread_mutex_destroy()ing
> the mutex help here?
*blech* You are right. My fix is busted :(
If we mark the mutex errorcheck and we deallocate it then what you
suggest might work. I'd have to research how robust
PTHREAD_MUTEX_ERRORCHECK really is and how robust it is guaranteed to
be. But then all the pthread mutex operations we did on that mutex
could fail which would fan out through the code.
I think the real way to do this is to reference count anything that can
be held by multiple threads. That'll also fan out through the code but
there are fewer error paths and we can prove it works fairly easily.
mph
>
> Alan
