Tom Chen writes: > Hi Paul, > Could you give more explanation on your previous reply? Do you mean that I > should release all locks before re-scheduling timer in the timeout handler? > > [b]"Don't take a lock within your timeout function that's held across > schedulng it. That can lead to precisely the sort of cycle you're > experiencing...."[/b] > > In my 1 second timer handler, after job is done, it calls timeout( ) to > re-schedule itself, so the qla_timer( ) can be called again at next second, > but I did not release mutex before calling timeout( ). Is this the true > origin of the deadlock?
I don't believe that's the case. If you look at the timeout(9F) man page, only untimeout(9F) has such warnings on it. It does because it's possible that _during_ the call to untimeout(9F), you may block because your callback is already running on another thread, and you'd thus deadlock with yourself. No such warning accompanies timeout(9F). The usual reason for a deadlock is either a lock-ordering problem (A-B in one thread, B-A in another) or the wrong priority for the mutex (see mutex_init(9F)). -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
