Latences...

Tout d'abord la référence : la programmation temps-réel a ses normes : POSIX 4d9, devenu POSIX 1003.1b-1993 puis POSIX 1003.1i-1995. Totu cela indique comment coder une application utilisateur qui se comporte d'une certaine manière et quelles sont les obligations et/ou bonnes partiques d'un OS en terme de réponse.

Du point de vue d'une application, le temps est continu, la seule chose à prendre en compte est que le temps entre deux "gettimeofday" est foncièrement indécidable. L'important donc pour un code en mode utilisateur, c'est essentiellement de pouvoir réquisitionner le processeur dans des temps bornés (réaction à sollicitation), ou en temps prévu (interval timer).

Or cette réquisition va se faire moyennant un certain délai, entièrement du ressort de l'OS : le temps d'interrompre une tâche (user ou kernel) en cours, le temps de sélectionner la tâche à éxécuter, le temps de reprendre.

Concernant la reprise, le temps peut être considéré comme à peu près constant, il s'agit d'un temps de commutation de contexte très peu dépendant du processus à réactiver (la seule dépendance, liée à la présence ou non du code à réactiver dans le cache, n'est pas maitrisable). Sur ce point on peut donc trouver un temps majorant assez simplement.

L'interruption d'un processus utilisateur est de la même veine. Dans le cas particulier, donc, d'un processus utilisateur à interrompre, la qualité temps réel de la réquisition du processeur par le système pau profit d'un autre processus est complètement liée à la qualité temps réel de la sélection du processus à sélectionner (le scheduler).

Cas un peu plus complexe mais très fréquent : la sollicitation arrive sous forme d'une interruption. En rajoutant l'hypothèse que le processus en cours est un processus utilisateur. C'est un cas qui peut se ramener rapidement au précédent, puisque la commutation de tâches dans un système à temps partagé se fait en programmant un générateur d'interruptions (timer). On a donc "simplement" rajouté le temps de traitement particulier de l'interruption considérée - et ôté la durée du handler du timer.

Les *vrais cas difficiles c'est quand on interrompt un bout de code kernel.