On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote: > I know that the rule is to never block in a real time audio thread, > but what about blocking for resources shared between real-time > threads? In the case of a sequencing app that uses one thread per > audio/instrument track (as most do), is it OK to share a lock between > real time scheduled tracks?
Maybe. In theory it should be OK, I don't know enough scheduler magic to be certain. > Also, I've gathered are that adding app-thread => RT-thread > message-passing to avoid using locks while modify the application's > basic shared data structures is useless, since the real-time thread > will have to wait for execution of that code one way or another, given > the overhead of acquiring the lock is negligable. This would mean that > you should just use locks and assume the user will cope with hearing > small overruns when adding/removing audio components. True? Not true? Not true. The point with message-passing instead of locking a shared structure is that the RT thread doesn't access the shared structure in the first place - it has its own copy of the parameters it needs and can keep on producing audio until it receives a message, at which point it just changes its parameters in some RT-safe way (pointer swap etc) and goes on producing audio. No glitch. --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
