Jean-Christophe Dubois wrote:
> Last if we are considering cells with threads of equal priority, OKL4 shall
> run these various threads in round-robin mode. But all threads will
> necessarily get the same scheduling time. I can't find an easy way to instruct
> OKL4 that for 2 threads of the same priority, one should get twice as much CPU
> time than the other one. Is there a way to allocate CPU resource to the
> various cells/threads in a fine grained way?
Modulo OKL4 API, which may or may not allow this approach, a crude,
coarse-grained but simple and effective way to do this is to have a
master (scheduler) thread S running at high(er) priority H, and a number
of slaves (worker) threads A, B..., which implement various parts of
your applications, and are ready to run at the same (lower) priority L.
The scheduler thread starts the worker threads, and then yield()s to
them in a controlled (programmed) way. Each worker thread A, B... will
run for the duration of the timeslice (or until it blocks). Then the
control will (eventually) return to the scheduler thread, which can
yield() to another thread, or the same thread if the current one must
have an higher chance to run.
The scheduler thread can easily keep an account of how many times it
yielded to each thread, as a proxy to how much it (had a chance to) run.
In the long run, yielding to A 2x times than to B should approximate
giving A twice the amount of CPU time given to B (assuming that A,B...
are all CPU intensive, and don't block often).
Note that by having every worker thread run at the same priority allows
them to interact in IPC without penalising or favouring one over the
others. If A IPCs to B, B will run on A's timeslice (donated by S), but
eventually it will end, and the control return to S (this also implies
that until B does not get to run, it can't finish its job for A, and A
is stuck, no matter how many times S yields to A... but that's priority
inversion, a classic RT scheduling can of worms...).
Moreover, no worker thread gone mad can starve other worker threads,
again because it will be preempted after a timeslice anyway, and the
control returned to the scheduler thread S.
>
> BTW, now that there is no more "privileged" cell (as opposed to OKL4 2.4) how
> could one cell theoretically restart another cell that is crashed/has gone
> mad? We can certainly reset the all system but is there a finer grained way to
> do it?
Worker threads gone mad can be stopped by requiring them to notify the
scheduler with a watchdog signal (e.g., an async notify), emitted in
critical points of the code meaning "Hi S, I am working fine, please
yield to me again!".
If S does not receive a notify after yielding k(*) times to thread X, it
assumes that X went mad, thus stops yielding to X and takes appropriate
recovery actions, such as re-start thread X.
Ciao,
Sergio
(*) Of course the right value of k is application-dependent, and it is
left as an exercise to the reader :-)
--
Dr. Sergio Ruocco Research Fellow
http://www.disco.unimib.it/ruoccomailto:
[hidden email] /
[hidden email] NOMADIS Lab
phone: +39-02-6448-7914 Mobile, embedded real-time systems
skype: 'sergioruocco' Dip. di Informatica, Sistemistica e COmunicazione
Building U14, room 1003 Università degli Studi di Milano-Bicocca, Italy
_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer
