Subject: Re: [linux-audio-dev] deadlocks contd
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe joulu 10 1999 - 22:30:43 EST
>Am I correct that a deadlock can only occur where I try to lock more
>than one mutex? Now I did a grep -15 mutex_lock over my .cc files and
>found only one piece of code where I lock two mutexes: when I start the
>audio-enigne. Now the stalls occur while playing when that code is no
>longer relevant.
depends on what you mean by deadlock. what you referring to is
normally termed "livelock".
the way that pthread mutexes are implemented (under Linux anyway)
cannot cause your box to deadlock in the sense of "total lockup", even
if the lock-hungry threads are SCHED_FIFO. Thats because Pthreads
sigsuspend()'s each thread wanting a locked mutex, and it won't wake
up again until it is sent a POSIX signal when the lock is freed. The
only way to get pthread mutexes to cause machine-level "total lockup"
is to use pthread_mutex_trylock().
a more common form of "deadlock" is based around just a single lock.
this can happen inadvertently when just a single thread takes a lock,
and then calls pthread_mutex_lock() again instead of
pthread_mutex_unlock(). This happens to me from time to time when I
use emacs to cut and paste "pthread_mutex_lock(...)" a little too
carelessly. whenever i get a thread jammed somehow, it normally turns
out that i was doing this, and i look carefully for pairs of
lock/unlock calls. i also try to be very, very careful about ensuring
that there is a well defined lock heirarchy and a well defined lock
order (often the same thing), so that lock acquisition and release is
always in the same order.
so, you need to be more specific about what you mean by "deadlock". if
the box is totally jammed, and you don't use pthread_mutex_trylock in
a spin-loop, then pthread mutexes are not responsible.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST