Utilisation de sleep ou de timer ?

Version imprimable

15/04/2015, 17h26
victorienv

Utilisation de sleep ou de timer ?

Bonjour,
Je dois développer un programme pour un os linux 3.14 embarqué (sur processeur arm) en langage C et, n'étant expert en développement, je me pose la question de la meilleure implémentation à faire.
Mon programme est assez simple et réalise la fonction suivante : toute les secondes, il va consulter l'état d'un fichier pour mettre à jour l'état d'une led.
Ma question concerne le timing de l'action à réaliser toutes les secondes ; sur ce que j'ai lu, il y aurai 2 façon de faire :
- utiliser sleep dans une boucle while(1)
- utiliser des timer avec timer_create et timer_settime

Quels sont les avantages/inconvénients de chaque solution ?

Merci d'avance
15/04/2015, 19h28
hisoft

Bonjour,
Est-ce une obligation de passer par du C car si ce n'est que l'automatisation que tu vises, il est possible de la faire simplement via cron ?
A+
15/04/2015, 21h26
hurukan

Si mes souvenirs sont bons: cron permet d'exécuter une commande (un programme) à intervalle régulier (toutes les secondes c'est possible).

Par contre il faut que le programme soit accessible par "cron" (permissions, droits d'accès, ...), chaque utilisateur à son propre "crontab", il faut y penser.

Je pense que dans ta question il y a une volonté d'aller vers la solution la plus "simple" à mettre en œuvre, le while(1) avec un sleep(1) dedans devrait convenir.

Je ne suis pas un expert en temps réel, mais je pense que sleep(1) suffira pour faire le test des valeurs et allumer ou non la led (là aussi je ne suis pas électronicien je ne sais pas si une led prend l'état 0 ou 1 ou une valeur analogique) chaque seconde écoulée.

Le timer serait plus approprié si plusieurs processus devaient appeler une fonction particulière au bout d'un certain temps: dans le contexte "asynchrone". Un "time out" dans un processus qui vérifie l'existence d'une connexion, par exemple. On sait que c'est après trois secondes,
par exemple, que le "timer" va déclencher l'appel de la fonction pour indiquer que la connexion est perdue, par exemple, mais ce n'est pas toutes les trois secondes que la fonction va être appelée. Des fois ce sera effectivement après trois secondes, manque de bol, et des fois pas du tout.

Je ne sais pas si je m'exprime correctement.

Ici si tu es certain que tes opérations doivent s'exécuter toutes les secondes je pense que ça ne sert pas à grand chose de mettre un "timer" sur le champs de bataille, un sleep(1) suffit.
15/04/2015, 22h52
BufferBob

salut,

Citation:

Envoyé par victorienv

Quels sont les avantages/inconvénients de chaque solution ?

difficile à dire je ne fais pas d'embarqué pour ma part et je ne connais pas non plus les contraintes liées à ton programme en l’occurrence

j'aurais tendance à penser que si ton programme ne fait rien d'autre, un sleep() fera parfaitement l'affaire, là où timer_settime() lèvera probablement une interruption qui pour autant ne fera pas dormir ton while(1) qui même s'il n'exécute "presque rien" affichera une conso de 100% cpu

en revanche la granularité de cron est de l'ordre de la minute, je te confirme que ça n'est pas une alternative dans ton cas
15/04/2015, 23h16
Invité

Niveau avantage et inconvénient ... Je ne saurai dire.

Par contre, je pense que le le timer est bien plus approprié ici qu'un sleep.

Pourquoi ?
Un timer donne une référence de temps précise, calé sur l'horloge du cpu. A contrario, sleep() donne une échéance de temps ~1sec. sleep() est moins précis donc.

Une solution a base de while(1) { sleep(1); } à l'inconvénient d'une part de ne pas être calé toute les 1secondes (dû au fait de l'imprécision de sleep), et d'autre part de "perdre" le temps de l'exécution des instructions de lecture ui viennent après ton sleep.

Utiliser un timer périodique te permet d'être sûr d'être toujours calé à la seconde prêt, et que l'exécution des instructions de lecture n’empiéteront pas sur le décomptes.
Concrètement, dans le code, il suffira d'armer le signal correspondant au timer, d'armer le timer en périodique, et dans le handler de signal y mettre les instructions de lecture. Cela te permet, dans le code, d'effectuer d'autre opération avant de te caler sur un while(1) { pause(); }.

En espérant pouvoir t'aider ainsi.. !
15/04/2015, 23h45
BufferBob

Citation:

Envoyé par archMqx.

je pense que le le timer est bien plus approprié ici qu'un sleep.

ben justement, je pense que c'est le contraire ici, pourtant je comprends bien ton raisonnement

Citation:

Un timer donne une référence de temps précise, calé sur l'horloge du cpu. A contrario, sleep() donne une échéance de temps ~1sec. sleep() est moins précis donc.

voila je me suis dit la même chose, c'est pour ça que je précisais qu'on ne connait pas ses contraintes ici, mais vois la chose sous un angle différent; sleep() libère l'ordonnanceur qui réactivera le processus au bout du temps voulu, le temps d'exécution des instructions qui suivent, si elles ne font que checker un fichier est de l'ordre de quelques microsecondes, mais sleep() libèrera le CPU pour mettre le processus en sommeil, tandis que le timer sera effectivement possiblement plus fin, plus "absolu", mais génèrera potentiellement plus d'aio

sans parler du fait que celui qui réveille le processus suite à un sleep() ou déclenche l'interruption dans le cas d'un timer, dans les deux cas c'est le noyau à travers l'ordonnanceur, y'a peu de chances que la seconde chez sleep() en dure réellement 0.999s ;)

en fait à bien y réfléchir je me demande même il n'y a pas moyen de coupler les deux un peu habilement, de manière à tourner sur plusieurs itérations autour de sleep() et enrouler un timer autour pour faire une sorte d'auto-correction (par exemple toutes les 10s en relançant 10 itérations de sleep())

reste que tout dépend son besoin réel derrière, si ça se trouve un morceau de bash lui conviendrait aussi bien :mrgreen:
16/04/2015, 08h47
Bktero

Citation:

Quels sont les avantages/inconvénients de chaque solution ?

La vraie question à se poser est : que doit faire le système dans son ensemble ?

Si tu t'amuses juste à faire clignoter une LED, sleep() est très bien pour ça.

Si en revanche ton programme doit faire plein de choses dont faire clignoter la LED, ça devient différent. Tu peux "gaspiller" un thread à faire ton while() et tes sleep(). Quand tu voudras faire une acquisition toutes les 30 secondes sur un ADC, tu feras un autre thread. Et ainsi de suite. Si tu as plein d'actions à exécuter périodiquement, il est clair qu'il faut mieux passer par un système qui te permet de planifier facilement*. Je n'ai pas utilisé ces fonctions de Linux, mais des mécaniques similaires. Avec un MCU, j'utilise des timers et je fais mes actions dans la routine d'interruption. En Java, j'utilise des Timer et des TimerTasks (voir cet article que j'ai écrit : http://www.is2t.com/periodic-actions-timer-timertask/).

* Après, cela dépend de ton système, de la mémoire à ta disposition, de tes contraintes temps réelles plus ou moins fortes, de ta volonté d'économiser de l'énergie. Ca ramène en fait à ma question du début.

Pour la précision de sleep(), on peut toujours utiliser d'autres fonctions telles que nanosleep() (http://linux.die.net/man/2/nanosleep). En regardant ce que donnait usleep(), j'ai vu qu'elle était obsolète, pour information.
16/04/2015, 09h30
victorienv

Merci pour toute vos réponses. Et pour vous répondre :
- J'avais pensé a cron mais d'après ce que j'ai lu (et vous l'avez confirmé) cet outils n'est pas vraiment approprié pour déclenché des actions à des intervalles aussi court.
- Comme dit, si on utilise un timer avec un while(1){ pause(); } ou simplement un sleep, on ne charge pas plus le cpu
- Ce programme n'a pas besoin d'une base de temps très précise car on n'utilise pas le temps pour faire clignoter la led ; juste pour actualiser les états périodiquement. La perdre de plus ou moins quelques micro ou milliseconde du à un chargement d’instruction n'est pas critique.
- Ce programme n’exécute pas d'autres taches ; il est utilisé comme un "démon" qui es chargé au démarrage de la carte pour mettre à jour l'état des leds tout au long de la période de fonctionnement. E revanche dans le projet complet il y a un autre programme qui effectue d'autre tache.
- Un des points qui me fait hésiter avec le sleep est le suivant : mon projet étant de l'embarqué, je vais être amené à mettre linux dans un état de standby (j'aurai peut être du le préciser dans mon 1er post). Mon programme tournant en permanence, il y a 99% de chance que la mise en standby tombe pendant l’exécution du sleep. Une personne (avec qui je n'ai pas pu discuté) n'avait dit que l'utilisation de sleep pouvait poser des problèmes avec le standby et qu'il fallait le gérer autrement (mais sans m'expliquer comment).