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?
Alan
