Subject: Re: [linux-audio-dev] Re: mutex madness
From: est_AT_hyperreal.org
Date: to syys 30 1999 - 19:26:48 EDT
Paul Barton-Davis discourseth:
>
> things can more unpredictable, however, if you add one more runnable
> thread to the entire OS thread list. if this thread gets to run
> instead of the UI thread while the UI thread still holds the lock on
> the queue, then the DSP thread is out of luck, and so are we. this is
> even more likely (to the extent that it *is* likely at all) if the
> input thread is has RT scheduling.
>
> so, the above scheme will work most of the time, but still can't
> guarantee that the dsp will get the lock when it needs to. even
> turning the mutex into a "fair" one won't help this pathological
> condition.
>
> BTW, you could work around this by making the UI thread run
> SCHED_FIFO, but this causes a lot of other problems, especially on a
> UP system.
Assuming the dsp is given a higher static priority than the gui, what
are these problems?
Maybe a queue that makes the lock/operate/unlock atomic would be
useful..say, a pipe! A million write()/read()s of 1 byte through a
pipe takes less than 2.5 seconds on my system..not bad.
> [...]
> so we just need to focus on designs that minimize the communication
> between threads. BTW, this is another reason for my appreciation of
> quasimodo's asynch parameter update model:
Yeah..simple is nice. Is modification of the dsp done in real-time in
q, or is is just `interactive'?
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST