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. > 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? Perhaps what I'm not clear about here, is which mutex is the one that we are stuck on? Are we stuck on the mutex we want to pass to pthread_cond_timedwait? Cheers, Carlos. -- 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
