Supposons que vous développiez en C sur
Unix et que vous deviez suspendre l'exécution
du programme pendant exactement N μs. Par exemple, vous voulez envoyer
des paquets sur le réseau à un rythme donné. La
réaction immédiate est d'utiliser sleep. Mais il y a en
fait plein de pièges derrière ce but a priori simple.
Le plus évident est que sleep prend en
argument un nombre entier de secondes :
unsigned int sleep(unsigned int seconds);
Sa résolution est donc très limitée. Qu'à cela ne tienne, se dit le
programmeur courageux, je vais passer à
usleep :
int usleep(useconds_t usec);
Celui-ci
fournit une résolution exprimée en μs et, là, on va pouvoir attendre
pendant une durée très courte. Testons cela en lançant un chronomètre
avant l'appel à
usleep() et en l'arrêtant après,
pour mesurer le temps réellement écoulé :
% ./usleep 1000000
1 seconds and 67 microseconds elapsed
OK, pour une attente d'une seconde, le résultat est à peu près ce
qu'on attendait. Mais pas à la μs près. Le
noyau est un Linux,
système multitâche
préemptif et des tas d'autres tâches tournaient
sur la machine, le noyau a donc d'autres choses
à faire et un programme ne peut pas espérer avoir une durée d'attente
parfaitement contrôlée. Ici, l'erreur n'était que de 0,0067 %. Mais si
je demande des durées plus courtes :
% ./usleep 100
0 seconds and 168 microseconds elapsed
J'ai cette fois 68 % d'erreur. La durée écoulée en trop (le temps que
l'ordonnanceur Linux remette mon programme en route) est la même mais
cela fait bien plus mal sur de courtes durées. Bref, si
usleep() a une résolution théorique de la
microseconde, on ne peut pas espérer avoir d'aussi courtes durées
d'attente :
% ./usleep 1
0 seconds and 65 microseconds elapsed
Avec une telle attente minimale, un programme qui, par exemple,
enverrait à intervalles réguliers des paquets sur le réseau serait
limité à environ 15 000 paquets par seconde. Pas assez pour certains usages.
Là, le programmeur va lire des choses sur le Web et se dire qu'il
faut utiliser nanosleep :
struct timespec
{
__time_t tv_sec; /* Seconds. */
long int tv_nsec; /* Nanoseconds. */
};
int nanosleep(const struct timespec *req, struct timespec *rem);
Celui-ci permet d'exprimer des
durées en nanosecondes, cela doit vouloir dire qu'il peut faire mieux
que
usleep(), non ?
% ./nsleep 1000
0 seconds and 67 microseconds elapsed
Eh bien non. Le problème n'est pas dans la résolution de la durée
passée en argument, il est dans l'ordonnanceur
de Linux. (À noter qu'il existe d'autres bonnes raisons d'utiliser
nanosleep() plutôt que
usleep(), liées au traitement des
signaux.) La seule solution est donc de changer
d'ordonnanceur. Il existe des tas
de mécanismes pour cela, allant jusqu'à la recompilation du noyau avec
des options davantage « temps réel ». Ici, on
se contentera d'appeler
sched_setscheduler() qui
permet de choisir un nouvel ordonnanceur. Attention, cela implique
d'être root, d'où le changement
d'invite dans les exemples :
# ./nsleep-realtime 1000
0 seconds and 16 microseconds elapsed
Le noyau utilisé n'est pas réellement temps-réel mais, en utilisant
l'ordonnanceur
SCHED_RR, on a gagné un peu et les
durées d'attente sont plus proches de ce qu'on demandait. (Les gens
qui veulent de la latence vraiment courte, par exemple pour le jeu
vidéo, utilisent des noyaux spéciaux.)
Ce très court article ne fait qu'effleurer le problème compliqué
de l'attente sur un système Unix. Il existe par exemple d'autres
façons d'attendre (attente
active, select sur aucun fichier, mais avec
délai d'attente maximal, dormir mais jusqu'à un certain moment comme illustré par ce programme,
etc).
Je vous conseille la lecture de
« High-resolution
timing » et de « Cyclictest »
ainsi évidemment que celle de StackOverflow. Le
code source des programmes utilisé ici est usleep.c et
nsleep.c. Plus compliqué, le programme test_rt4.c utilise des timers, des
signaux, bloque le programme sur un seul processeur, interdit le
swap et autres trucs pour
améliorer la précision.
Merci à Michal Toma pour l'idée, à Laurent Thomas pour son code et
à Robert Edmonds pour plein de suggestions.
