d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?
Là, tu me poses une colle. Je ne joue pas à ça. À une priorité donnée, je mets soit RR soit FIFO, mais pas les deux. Il faudrait regarder ce qui est marqué dans la norme POSIX. Mais il y a toujours un risque sur l’implémentation sur le système que tu utilises. Quand on passe les tâches en TR, c’est pour gagner en maîtrise, ce n’est pas pour ajouter de l’incertitude. Donc je ne le ferai pas.
Instinctivement, je dirai que FIFO 10 est plus prioritaire que RR 10, mais moins que RR11. Mais je n’ai jamais essayé de mixer.
Je cite (vu sur un site) :
"(...). N’étant
pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"
Il parle de processus de même priorité. C’est pour alerter que les autres tâches n’auront pas de CPU (en multi cœur c’est faux), et que ça peut bloquer l’ordi. Je vois ça plus comme une mise en garde. Mais je t’accorde que c’est imprécis.
je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.
Non, la tâche sera bien interrompu par des tâches plus prioritaire.
si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY.
Je ne sais pas ce que tu veux faire. Le temps réel est quelques chose de particulier. Si tu veux faire de l’applicatif « normal » n’utilise pas. L’objectif du temps réel est de garantir des temps de réponse, pas d’aller vite. Donc toute ton architecture se base sur des euristiques de temps de traitement de chaque tâche, et chaque tâche répond a un stimuli auquel on veut répondre.
Ex: J’ai une tâche qui surveille la monté d’eau dans un aquarium. Je connais le débit d’eau, la hauteur au dessus de mon capteur, donc je sais déterminer combien de temps il me reste quand le capteur me dit plein. On enlève un peu de temps, il y a potentiellement des remous ou que sais-je.
À partir de ta cascade d’événements, qui produisent des réponses pouvant être des stimuli d’autres tâches.
Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?
Normalement, quand tu mets une tâche en SCHED_FIFO, c’est qu’elle est suffisamment courte.
[^] # Re: Définir non préemptif...
Posté par Anthony Jaguenaud . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 2.
Là, tu me poses une colle. Je ne joue pas à ça. À une priorité donnée, je mets soit RR soit FIFO, mais pas les deux. Il faudrait regarder ce qui est marqué dans la norme POSIX. Mais il y a toujours un risque sur l’implémentation sur le système que tu utilises. Quand on passe les tâches en TR, c’est pour gagner en maîtrise, ce n’est pas pour ajouter de l’incertitude. Donc je ne le ferai pas.
Instinctivement, je dirai que FIFO 10 est plus prioritaire que RR 10, mais moins que RR11. Mais je n’ai jamais essayé de mixer.
Il parle de processus de même priorité. C’est pour alerter que les autres tâches n’auront pas de CPU (en multi cœur c’est faux), et que ça peut bloquer l’ordi. Je vois ça plus comme une mise en garde. Mais je t’accorde que c’est imprécis.
Non, la tâche sera bien interrompu par des tâches plus prioritaire.
Je ne sais pas ce que tu veux faire. Le temps réel est quelques chose de particulier. Si tu veux faire de l’applicatif « normal » n’utilise pas. L’objectif du temps réel est de garantir des temps de réponse, pas d’aller vite. Donc toute ton architecture se base sur des euristiques de temps de traitement de chaque tâche, et chaque tâche répond a un stimuli auquel on veut répondre.
Ex: J’ai une tâche qui surveille la monté d’eau dans un aquarium. Je connais le débit d’eau, la hauteur au dessus de mon capteur, donc je sais déterminer combien de temps il me reste quand le capteur me dit plein. On enlève un peu de temps, il y a potentiellement des remous ou que sais-je.
À partir de ta cascade d’événements, qui produisent des réponses pouvant être des stimuli d’autres tâches.
Normalement, quand tu mets une tâche en SCHED_FIFO, c’est qu’elle est suffisamment courte.