On Wed, 23 Dec 2009, Carlos O'Donell wrote: > On Wed, Dec 23, 2009 at 11:15 AM, John David Anglin > <dave@xxxxxxxxxxxxxxxxxx> wrote: > >> There will never be a timeout if you call pthread_mutex_lock as the > >> underlying operation. So this comment is a bit odd? > > > > The wait is done by Tcl_ConditionWait. It uses pthread_cond_wait > > if timePtr is NULL, otherwise it uses > > pthread_cond_timedwait(pcondPtr, pmutexPtr, &ptime). Do these work > > holding a lock? Any chance that these try to take a lock? > > When you call pthread_cond_timedwait you must be holding pmutexPtr. > > The call to pthread_cond_timedwait atomically release mutex and cause > the calling thread to sleep on the condition variable cond; atomically > here means "atomically with respect to access by another thread to > the mutex and then the condition variable". Once awoken by a broadcast, > it retakes the mutex pmutexPtr. > > The glibc implementation with futexes reads pretty much exactly like > the description here: > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_timedwait.html > > > It sems like bad coding to do a wait holding a lock. In any case, > > I don't think this is the problem. > > You shouldn't be holding a lock while waiting. The call to > pthread_cond_timedwait > should have released the mutex before sleeping. No, the manpage for pthread_cond_wait and pthread_cond_timedwait indicates that these calls atomically unlock the mutex, so the implementation appears correct. Before returning to the calling thread, they relock the mutex. So, the mutex shouldn't be held while the thread is sleeping. > > > 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. > > It shouldn't deadlock. > > Is this a UP kernel? Yes. This has now happened twice in one testsuite run. > Perhaps what I'm not clear about here, is which mutex is the one that > we are stuck on? notifierMutex. It controls all activities in tclUnixNotfy.c. > Are we stuck on the mutex we want to pass to pthread_cond_timedwait? Yes. 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
