Hi,
On Wednesday 25 November 2009 11:17:39 mutil wrote:
I am trying to write a c++/qt4 jack client which mix
2 inputs and has a
jack output. The problem is that currently jack gets zombified too often
and I would like some info on how can I debug the exact reason this
happens. I suspect it's the way the app is written and I am planning to
rewrite it but I need some advices first.
The way it's currently written makes use of mutexes and locks to pass the
data beetween a custom global buffer. Is this the reason for not
synchronizing good enough and zombifies jack or it's something else that
screw things?
Locks and waits are not realtime save. So don't ever use them in a realtime
thread. When the realtime thread is waiting on the gui-thread to release a
lock, why separate the threads at first and give one higher priority?
Should I use a ringbuffer (which, to my understanding
is
lock-free and doesn't need mutexes) to get the work done, and if so, are
there any jack2 example of this or some hints for what I should be aware
of?
Ringbuffers are only lock-free when one thread is always _only_ reading and the
other is always _only_ writing. But for an (usable!) example of a lock-free
ringbuffer, see ringbuffer.h shipped with jack. Guess what its intended usage is
;-)
Or have I misunderstand something completely?
Please, any recommendation of how I can eliminate this "jack zombified"
thing and understand the whole realtime issue is welcome.
Basically multiple threads should not wait on each other. If they have to
wait, they are depending deep enough to become one. If one thread is supposed
to work realtime, don't ever make it wait, that is don't use locks, don't
acquire or release memory with malloc/free/new/delete...
Arnold