On Thu, 2009-09-24 at 14:17 +0100, Alan Maguire 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?
On a related note, stress tests should be run to find edge cases like this. I'd recommend writing a simple stress test that manipulates these objects through the door from multiple processes in order to validate your locking design and implementation. -Seb
