5 Dec
2009
5 Dec
'09
12:09 p.m.
On Wed, Dec 02, 2009 at 01:15:08PM +0100, fons(a)kokkinizita.net wrote:
On Wed, Dec 02, 2009 at 12:32:12PM +0100, Arnold
Krille wrote:
hmm... but thats the trigger semaphore.
and the worker thread blocks on it. so the process thread cant block on
it. or are you talking about some non released code ?
On Wednesday 02 December 2009 11:09:18
fons(a)kokkinizita.net wrote:
It's not the only solution but surely the easiest.
The semaphores that would be required are already
in place (they are used for checking readyness now). non-RT, while these extra threads remain at RT.
So
they will pre-empts Jack's thread and will appear to
be always ready on time. Except when you have 2 CPUs:
then Jack's thread will be allowed to continue even
if some of the others have not yet completed their
work.
Wouldn't the easiest solution be to wait for the worker-threads when in
freewheeling mode?
The complicated part could be switching between the
two regimes. I suspect this can't be done 'instantly',
it could require a multi-step process spread over a
series of periods.
Maybe I'm overestimating the complexity, but I try
to step gently as organising the cooperation of these
threads was not a simple task. The code looks simple,
but that's the result of my usual irresistable urge
to simplify every algorithm down to its essentials.
I've not really tried to solve this ATM, but will do
if some free time drops from the (currently) blue
Italian sky.
i added a semaphore like construct built with pthread_cond
the RT thread only decrements the counter and in sync mode
wait for the counter to be zero.
this allows instant switching.
using more than 1 line for syncying clutters the code though, but as
this kind of stuff is a matter of taste, i leave that up to you to
move it into a separate method or class.
patch is attached
--
torben Hohn