Subject: Re: [linux-audio-dev] SCHED_FIFO machine stalls
From: su sn (sn_AT_vega.interaction.de)
Date: la joulu 11 1999 - 08:13:34 EST
I noticed simular problems some time ago when writing my RTSynth
application.
At this time the program had the following layout:
- Audio/Synth thread with RT priority
- Midi input thread with RT priority
- GUI thread with normal priority
from time to time the application went into a dead lock, which
did not happen if all threads where added to the same scheduler!
I tried hard to figure out what the problem was (mutex_lock/unlock
problems etc..) but didn't found a solution. To me it looked like
a general scheduler/thread bug.
I noticed this problem with both linux 2.0.35 using pthreads and with
linux 2.2.5.
To get rid of this problem together with some other problems I had
with the FLTK tool kit (at this time there was no multi thread support
available) I changed the layout to:
- Main program running with RT priority managing the GUI and the
Audio/Synth things. BTW this results in a noticeable reduction
of CPU load.
- Midi input thread with RT priority
With this layout everything works fine except for CPU overload
conditions which block the hole system. I also noticed a heavy bug with
pipes: when the writer to a pipe get killed the reader eats all CPU power.
Don't think this is posix conform.
To handle this conditions I added a "vital" thread running at normal
priority with nice 1. Every real time thread has a global variable which
is increased on each loop and after reaching a given limit the thread
stops itself or sleeps for a given time. The low priority "vital" thread
resets those global variables in a given time interval. On CPU overload
the "vital" thread does not get any/enough CPU time -> no variable reset ->
the real time threads are stopped by them self.
On my system this works absolutely perfect under all conditions.
- Stefan
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST