Discussion :

[prog_]

Bonjour,

je suis débutante/intermédiaire en C++ (Visual Studio) et j'ai conçu un petit programme pour un projet qui permet de lire un fichier texte et d'enregistrer les valeurs voulus, contenus dans celui-ci. Par la suite, je fait un affichage des données receuillis avec les fonctions CDC (CRect,lineto,moveto,...) d'MFC dans un rectangle. Tout marche bien, cependant, il faut arriver à adapter ce programme en TEMPS RÉEL, ce qui n'est pas le cas pour l'instant, et je n'y connait vraiment rien....

En gros, on reçoit des données d'un tocographe (appareil permettant de détecter les contractions utérines) sur le fichier texte à toute les 0.25 secondes. Il faudrait donc que notre prog aille chercher les données voulus à chaque 0.25secondes dans le fichier texte et que notre fenêtre d'affichage soit rafraichit à ce même taux d'échantillonage...

Des idées ??? Des fonctions déja existantes en MFC ??
Merci énormément d'avance !!

[3DArchi]

Bonjour et bienvenu,
D'abord, il te faut estimer ce qui prend le + de temps : la lecture du fichier ou l'affichage.
Pour l'affichage, tu peux essayer un double buffering : tu fais ton rendu dans un CDC mémoire et tu fais juste un blit pour l'affichage.
Pour la lecture du fichier, il faudrait analyser ce qui prend du temps pour savoir vers quel axe rechercher les optimisations : chargement, lecture du fichier, construction des données ?

[JolyLoic]

Si tu veux t'approcher du temps réel, il faudra probablement séparer ton programme en deux parties, et en deux threads (voire deux processus) :
-Un, tournant en assez haute priorité, lisant les valeurs de ton tocographe et les écrivant dans une structure mémoire comme une queue, protégée par un mécanisme de synchronisation (mutex, critical_section...), mais ne faisant aucun appel au système de fichier ou à l'affichage
- Un autre, tournant en priorité normale, lisant les valeurs dans la queue précédente (en gardant le lock le moins longtemps possible), et gérant tous les aspects pour lesquels le timing n'est pas crucial (affichage, écriture dans un fichier...)

Cette architecture permettra d'éviter par exemple qu'un délai dans l'affichage (parce que l'utilisateur est ent rain de bouger une fenêtre, ou qu'un antivirus scanne un fichier) n'ait un impact trop important sur la tâche qui doit vraiment avoir lieu à fréquence bien définie.

[prog_]

Bonjour et bienvenu,
D'abord, il te faut estimer ce qui prend le + de temps : la lecture du fichier ou l'affichage.
Pour l'affichage, tu peux essayer un double buffering : tu fais ton rendu dans un CDC mémoire et tu fais juste un blit pour l'affichage.
Pour la lecture du fichier, il faudrait analyser ce qui prend du temps pour savoir vers quel axe rechercher les optimisations : chargement, lecture du fichier, construction des données ?

Merci pour votre ta réponse, elle est très appréciée.

Est-ce que tu sais vers quelles fonctions se tourner en MFC pour le blit?...J'ai rien trouvé sur le net, et puis, je suis pas hyper expérimentée..

[3DArchi]

Merci pour votre ta réponse, elle est très appréciée.

Est-ce que tu sais vers quelles fonctions se tourner en MFC pour le blit?...J'ai rien trouvé sur le net, et puis, je suis pas hyper expérimentée..

Salut,
Tu peux regarder cette discussion et ce lien.
P.S. : je regrette de ne pas avoir eu spontanément l'idée de Loïc qui me semble aussi une bonne piste à explorer .

[prog_]

Si tu veux t'approcher du temps réel, il faudra probablement séparer ton programme en deux parties, et en deux threads (voire deux processus) :
-Un, tournant en assez haute priorité, lisant les valeurs de ton tocographe et les écrivant dans une structure mémoire comme une queue, protégée par un mécanisme de synchronisation (mutex, critical_section...), mais ne faisant aucun appel au système de fichier ou à l'affichage
- Un autre, tournant en priorité normale, lisant les valeurs dans la queue précédente (en gardant le lock le moins longtemps possible), et gérant tous les aspects pour lesquels le timing n'est pas crucial (affichage, écriture dans un fichier...)

Cette architecture permettra d'éviter par exemple qu'un délai dans l'affichage (parce que l'utilisateur est ent rain de bouger une fenêtre, ou qu'un antivirus scanne un fichier) n'ait un impact trop important sur la tâche qui doit vraiment avoir lieu à fréquence bien définie.

merci pour l'idée Loic, je vais tenter de créer 2 threads !!

[Mac LAK]

+1 avec Loïc, bien que deux processus ne soient pas nécessaires sous Windows (un thread RT suffit bien amplement).

J'aurais tendance à faire trois étages, pour ma part :

1. Un thread de lecture depuis le fichier.
2. Un thread de "log" muet, ne faisant en fait que consigner la liste des évènements.
3. Un thread de MAJ du contrôle d'affichage.
4. Le reste de l'appli (thread principal, d'IHM, ...).

Le thread 1 écrit (uniquement) dans les données du thread 2, et le thread 3 ne fait que lire dans les données du thread 2.

Les réglages de priorité seront plus faciles à faire avec trois étages, et en se débrouillant bien, il est carrément possible de faire du lock-free.

[JolyLoic]

+1 avec Loïc, bien que deux processus ne soient pas nécessaires sous Windows (un thread RT suffit bien amplement).

En effet, en direct, ça ne sert à rien. Si j'ai mentionné cette possibilité, c'est parce que, si jamais la ponctualité du système n'est pas suffisante (ce dont je doute ici), il peut être utile d'évoluer avec comme architecture un noyau temps réel qui tourne en dessous de windows (j'avais utilisé WinRT à une époque), et dans ce cas une architecture à deux processus devient obligatoire.

[Mac LAK]

Effectivement, c'est requis avec un co-noyau. Toutefois, sur une machine moderne, il serait étonnant d'avoir à en venir à cette solution pour quelque chose qui arrive toutes les 250 ms, ce qui reste une base de temps "lente" pour Windows. Cela pourrait être différent avec une période proche du quantum de temps par défaut, bien entendu.

[prog_]

Est-ce que vous savez où je peut trouver de l'info sur la création de thread sur Visual MFC? J'ai jamais fait...

[Mac LAK]

Dans le tutoriel API Win32, notamment, et dans la FAQ VC++.

Attention, toutefois, si tu utilises les MFC : il faut alors utiliser les fonctions dédiées des MFC (classe CThread notamment), et non pas les fonctions "de base" qui ne te permettraient pas d'utiliser les MFC correctement.

[prog_]

Un problème subsiste toujours....Puisque mon fichier texte se construit au fur et à mesure de l'entrée des données (à toutes les 250ms) , comment faire pour synchroniser le déclenchement du fichier texte (qui est indépendant et donc sur lequel je n'ai pas de contrôle en soit, puisqu'il est fournit par un autre logiciel (Portmon de Microsoft)et dont je n'ais pas les codes sources) avec mon programme C++...

C'est-à-dire, comment faire pour qu'il y ait une cohérence entre le temps auquel nos données sont affichés et celui auquel les données sont inscrites sur le fichier texte?

Je pensais trouver dans un premier temps le end of file du fichier, ajouter un timer qui lui dit d'attendre 250 ms avant de continuer sa lecture...est-ce possible tout ça ?? Sinon avez-vous des idées ??

Merci, c'est grandement apprécié !!

[bruno_pages]

Bonjour,

à partir du moment où le producteur du fichier est un outil tier que vous ne pouvez pas modifier, la seule solution est effectivement de tester périodiquement s'il y a quelque chose de nouveau. L'API des fichiers n'offre pas de lecture bloquante comme c'est par exemple le cas pour un socket

pour savoir si vous devez réouvrir le fichier à chaque test ou si vous pouvez toujours utiliser le même descripteur le mieux est finalement d'essayé, car vous ne savez pas vraiment comment le fichier est mis à jour par le programme tier, et éventuellement comment la lecture gère son cache. En cas de doute réouvrez le fichier à chaque fois. Bien evidemment si vous réouvrez le fichier à chaque fois il ne faut pas bettement relire la partie déjà lue mais directement sauter au bon offset (genre lseek)

le problème suivant sera de décider quand arreter d'essayer de lire dans le fichier (sans doute via un arret de votre application)

[3DArchi]

Salut,
Win32 propose une API pour monitorer un répertoire (dont le changement de taille d'un fichier). Je ne sais pas si ça a la réactivité nécessaire, mais ça peut être une piste à tester. Doc MSDN : Directory Notification.

[prog_]

J'ai trouvé une façon de changer la position de mon curseur dans mon fichier texte, soit a chaque séquence d'entrée de données, puisque celle-ci est fixe (24 trames ou lignes par séquence). Donc, j'utilise une boucle qui ouvre et ferme le fichier à chaque 250 ms, et je trouve la position de mon curseur a la fin de chaque séquence, afin que cette position soit connu pour la lecture de la prochaine séquence...et sa marche !!!

Mais, l'utilisation de FindFirstChangeNotification semble interessante...je vais regardre plus en détails!