Pour maîtriser le temps Réel, il faut voir ça comme de l’échantillonnage en fréquence. Il te manque une donnée : le temps de réponse voulue.
Question 1 : À la réception du message au bout de combien de temps, l’action doit être réalisée ?
Question 2 : À la lecture du message, en combien de temps l’action est réalisée ?
À partir de là, tu peux déterminer et prouver que ton logiciel répond en temps et en heure.
Dans ton exemple, la réponse à la question 2 est : 4s.
Avec 4s de traitement, ta période ne peut descendre en dessous de 4s (voir un poil plus).
Disons 5s. Donc, tu peux garantir que le traitement sera réaliser 10s après la réception. Des fois ce sera 4,1s des fois 9,1s. Mais toujours moins de 10s.
Si tu n’as pas cette problématique de temps de réponse voulu, j’aurais tendance à utiliser des solutions bloquante de type : select pour la lecture et communication inter thread pour prévenir en sécurité de la réception. Cette solution sera sûrement plus réactive, mais le temps non garanti.
Question : As-tu vraiment besoin de la maîtrise de ton temps réel pour ton application ? Tu ne donne pas beaucoup de détail (OS ou Bare metal), plateforme, etc.
Si tu as un CPU multi cœur par exemple, et que tu peux dédier un cœur à ça, alors, tu peux faire un thread bloquant qui va te garantir une réponse en moins de 5s. Mais ton cœur n’est pas disponible pour autre chose... c’est un choix de design à faire.
# Problématique Temps Réel
Posté par Anthony Jaguenaud . En réponse au message Polling ou Interrupt ?. Évalué à 3.
Pour maîtriser le temps Réel, il faut voir ça comme de l’échantillonnage en fréquence. Il te manque une donnée : le temps de réponse voulue.
Question 1 : À la réception du message au bout de combien de temps, l’action doit être réalisée ?
Question 2 : À la lecture du message, en combien de temps l’action est réalisée ?
À partir de là, tu peux déterminer et prouver que ton logiciel répond en temps et en heure.
Dans ton exemple, la réponse à la question 2 est : 4s.
Avec 4s de traitement, ta période ne peut descendre en dessous de 4s (voir un poil plus).
Disons 5s. Donc, tu peux garantir que le traitement sera réaliser 10s après la réception. Des fois ce sera 4,1s des fois 9,1s. Mais toujours moins de 10s.
Si tu n’as pas cette problématique de temps de réponse voulu, j’aurais tendance à utiliser des solutions bloquante de type :
selectpour la lecture et communication inter thread pour prévenir en sécurité de la réception. Cette solution sera sûrement plus réactive, mais le temps non garanti.Question : As-tu vraiment besoin de la maîtrise de ton temps réel pour ton application ? Tu ne donne pas beaucoup de détail (OS ou Bare metal), plateforme, etc.
Si tu as un CPU multi cœur par exemple, et que tu peux dédier un cœur à ça, alors, tu peux faire un thread bloquant qui va te garantir une réponse en moins de 5s. Mais ton cœur n’est pas disponible pour autre chose... c’est un choix de design à faire.