Subject: Re: [linux-audio-dev] Re: mutex madness
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to syys 30 1999 - 22:29:09 EDT
>> 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?
There are no problems. I was forgetting that even SCHED_FIFO comes
with priority levels, and imagining it to be a monolithic scheduling
class.
>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.
yes, i am currently working on extended Karl Nelson's libsigc++ system
for asynchronous inter-thread callbacks, and a pipe is a key element
of this.
>> [...]
>> 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'?
well, i am not sure what you mean by "interactive", but i think i
would call it real time. here is a typical pseudo-call stack:
poll(2)
<various GTK event handling calls>
Gtk_Controller::motion_event ()
Parameter::set ();
Module::parameter_edit ();
<build run time edit list>
foreach_active_process (&DspProcess::run_time_edit, rte_list);
None of the above calls involve cross-thread communication, and the
end result is a single memory location (either a char * or a float)
gets modified. I *think* that its typically about 250 instructions or
less from when we return from getting the event from the X server to
when the memory location gets modified.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST