On Wed, 23 Dec 2009, John David Anglin wrote: > On Wed, 23 Dec 2009, John David Anglin wrote: > > > As you noted, the lock is held by the other thread. The return pc is > > beyond Tcl_WaitForEvent. The only users of the notifierMutex mutex > > are in tclUnixNotfy.c. The only interesting thing done holding the > > notifierMutex mutex in code after Tcl_WaitForEvent is to call > > Tcl_ConditionNotify. It calls pthread_cond_broadcast if the condition > > pointer isn't NULL. > > > > Could this deadlock? It's hard to see how it could since the mutex > > doesn't seem to be involved. > > Actually, I see that the mutex and futex are part of the pthread_cond_t > type, so pthread_cond_broadcast could deadlock if not implemented properly. The deadlock occurs at the third call to Tcl_MutexLock in NotifierThreadProc (tclUnixNotfy.c:997). This is in a while(1) loop, so I have to think the previous call to Tcl_MutexUnlock failed, possibly because of a call to Tcl_ConditionNotify. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
