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?
If a mutex that is held is destroyed, then things will go haywire. In the kernel, this will result in a kernel panic. In user-land, the outcome will likely be that the thread holding the mutex will never wake up, or the process will crash accessing uninitialized garbage. -Seb
