Question de conception: thread

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/02/2007, 22h44
Flophx

Question de conception: thread

Bonjour à tous, j'ai une question de conception pour les programmeurs confirmés que vous êtes:

J'ai un programme qui actuellement permet de créer un dossier sur une clé USB. Dans ce dossier, sont créés un fichier texte, puis un fichier vidéo, séquentiellement. Le fichier texte doit à terme recueillir des données issues de capteurs, le tout synchronisé avec la vidéo. D'où ma question:

Faut-il mettre le remplissage du fichier texte et l'acquisition vidéo dans des thread, ou vaut il mieux créer deux programmes indépendants qui sont lancés successivement au départ?? (sachant qu'une asynchronsation faible n'est pas rhédibitoire)...

Merci de me donner votre avis!!
BOnne soirée
F.
19/02/2007, 23h53
fearyourself

Ce n'est pas un problème de C mais un problème de conception.

Si tu as besoin de synchronisations -> des threads
Si tu as juste deux systèmes concurrents -> deux programmes différents

Cela dépend vraiment si les deux éléments devront discuter entre eux.

Jc
20/02/2007, 06h48
Flophx

Ils ne discutent pas ensemble, mais tourne en parallèle.... Donc deux sous programmes indépendants parait le plus adapté à ce que j'ai à faire?

(pour le forum, c'est parce que c'est programmé en C!!:lol: )
20/02/2007, 10h41
Emmanuel Delahaye

Citation:

Envoyé par Flophx

(pour le forum, c'est parce que c'est programmé en C!!:lol: )

Et ? Tu confonds encore conception et réalisation à ton age ?
20/02/2007, 12h04
souviron34

Citation:

Envoyé par Flophx

Ils ne discutent pas ensemble, mais tourne en parallèle.... Donc deux sous programmes indépendants parait le plus adapté à ce que j'ai à faire?

(pour le forum, c'est parce que c'est programmé en C!!:lol: )

En fait tout dépend de ce que tu veux faire..

Si ils sont en parallèle (lancés par exemple avec system("...&") ), tu ne pourras que difficilement contrôler une synchro (ou alors avec threads).

Si la synchro n'est que peu importante, pas de problème.

Si par contre la synchro est importante, pouquoi ne pas inclure la mise à jour du fichier texte DANS le code de la création de la vidéo ?

J'avoue qu'une phrase du style

Citation:

Envoyé par Flophx

...le tout synchronisé avec la vidéo.
....
(sachant qu'une asynchronsation faible n'est pas rhédibitoire)...

me laisse perplexe....
20/02/2007, 13h29
Flophx

Citation:

Envoyé par Emmanuel Delahaye

Et ? Tu confonds encore conception et réalisation à ton age ?

C'est par réflexe que j'ai écrit là, donc mea culpa

Citation:

J'avoue qu'une phrase du style
Citation:
Flophx a écrit :
...le tout synchronisé avec la vidéo.
....
(sachant qu'une asynchronsation faible n'est pas rhédibitoire)...

me laisse perplexe....

J'entendais cela à l'échelle du processeur, le temps de lancer les deux programmes , ca ne devrait pas faire une différence "visuelle" conséquente sur le PC de dépouillement...

Ensuite effectivement j'utilise une commande system() qui utilise streamer. Je délègue l'acquisition vidéo à ce programme...
20/02/2007, 14h11
souviron34

ok mais on n'est pas plus avancé sur ta contrainte... 8O

Que veux-tu faire exactement ?

Est-ce que c'est la génération de la vidéo qui doit être synchronisée avec le texte ?

est-ce que c'est la génération du texte qui doit être synchronisée avec l'écriture vidéo ?

est-ce que le texte doit contenir les références à la synchro vidéo ?

est-ce que les 2 doivent s'occuper de choses différentes mais démarrer et finir à peu près en même temps ?

....

.
20/02/2007, 15h51
Flophx

Lors de la mise sous tension du processeur, et après chargement de l'OS, il faut que démarre l'acquisition vidéo et l'acquisition données capteurs afin qu'au dépouillement il y est la vidéo avec les actions du pilote et sur la frame d'à côté l'évolution des différents paramètres (vitesse, altitude, position du manche)....
20/02/2007, 18h55
souviron34

et du coup c'est relativement indépendant, puisque ce sera pour APRES , non ?

C'est à la visualisation que tu veux que ce soit synchronisé, si je comprend bien...

me trompe-je ?
20/02/2007, 21h43
Flophx

voui, dans la première phase du projet (acquisition puis post traitement), c'est la visualisation qui doit être synchrone. Dans la deuxième phase (dont je ne devrais a priori pas m'occuper), ce sera de la télémétrie et traitement temps réel..

Donc indépendance = 2 programmes si j'ai bien compris?? Ou ca fait quand même plus classe les thread?
21/02/2007, 00h10
souviron34

Citation:

Envoyé par Flophx

Ou ca fait quand même plus classe les thread?

euhh pour ce genre de problème je ne me dirigerais pas sur ce qui fais le plus classe ou pas, mais sur ce qui fait le plus de sens..

Si je comprends ton problème, les processus de CREATION des fichiers sont INDEPENDANTS (une caméra, un réseau de capteurs), donc j'opterais pour 2 programmes (pour cette raison)
(exemple où le cas d'avoir un seul programme dans ce cas ne marche pas : tu as une panne sur la caméra, tu n'as plus aucune donnée .... :cry: ce qui n'est certainement pas le but recherché.....)

Et à la lecture, tu peux avoir 2 options :

ou tu fais un seul programme, qui lit et synchronise les 2 fichiers, ou tu as un programme séparé, avec un "scheduler" au milieu, qui par exemple lève des sémaphores pour l'un ou l'autre... Mais ça c'est encore un autre problème..

Mais de manière certaine d'après ton exposé du problème je prendrais 2 programmes distincts et non communicants....
21/02/2007, 11h22
Flophx

Ok, je comprends bien!!
Je souhaite procéder comme suit:

un premier programme crée le dossier (il a un nom correspondant à un moment précis et ca donne JJ/MM/AA/HH/mm), et à ce nom en mémoire, qu'il donne en paramètre aux deux autres (ce qui implique que ce soit ce "main" qui lance les deux autres programmes);

Ca revient à des commandes system successives, avec un "&"

Je n'utilise alors pas de thread
C'est dans la logique de ce qui a été dit??
21/02/2007, 12h43
souviron34
absolument..

en tous cas moi c'est ce que je ferais.... :D

Mais peut-être quelqu'un aura-t-il une autre idée ?

Et en ce qui concerne la lecture, comme je disais :
- soit j'opterais pour une architecture avec un gestionnaire qui envoie à 2 programmes d'affichage différents le même time code, libre à chacun de trouver (ou non) la bonne donnée et de l'afficher (par exemple si une image manque on reste sur l'ancienne, ou au contraire on affiche du gris, ou si une mesure manque là encore on reste sur l'ancienne valeur ou on efface tous les champs)
- soit je ferais un seul programme qui charge (ou tente de charger) les 2 données correspondantes au time code et affiche..
21/02/2007, 13h11
Flophx

Bien, pour la première partie, ca me va!!

POur répondre à tes interrogations, le programme de dépouillement se fait sous java, avec d'un côté un lecteur vidéo, de l'autre une thread qui lira les données préalamblement chargées, Puis en deux instructions successives, on déclenche ce qui faut...

J'ai une autre question, liée à une évolution quasi immédiate de mon programme: je voudrais pouvoir faire varier le nombre de caméra disponible; une première partie du programme cherche le nombre de caméras connectées, puis ensuite déclenche l'enregistrement des vidéos de chacune.

A ce moment, j'ai besoin de thread non?
21/02/2007, 13h25
souviron34

pourquoi ?

le principe system() peut se dupliquer en fonction du nombre de caméras non ?

maintenant, pratiquement, je ne sais pas comment se passerait sur ton système une acquisition simultanée de 10 caméras... Problèmes d'overhead ? de scheduling ? de mémoire ?

je suppose que c'est à tester en fonction ET du système ET de la machine ET des pilotages de caméras...

Mais comme je n'y connais rien en threads.... :roll: peut-être que je n'ai pas la bonne solution....
21/02/2007, 16h22
Flophx

Bon, je résume ce que je comprends (c'est le plus simple):

Une fois que j'ai un programme qui gère une acquisition de caméra, il me suffit de l'appeler autant de fois qu'il le faut pour gérer toutes mes camérasn (en tenant compte des éventuelles limitations dues au système).

Mais si par exemple, je voulais faire une acquisition vidéo telle que tous les trente secondes, je switche de caméra, alors il me faudrait des thread car il y a communication entre des programmes?

Quelqu'un aurait-il un exemple simple et concret d'utilisation d'une thread (histoire de me fixer les idées une bonne fois pour toute sur cela)??

Citation:

Envoyé par Flophx

Mais si par exemple, je voulais faire une acquisition vidéo telle que tous les trente secondes, je switche de caméra, alors il me faudrait des thread car il y a communication entre des programmes?

La je ne sais pas, mais à ce compte-là vraisemblablement le plus effiace serait DANS le programme qui fait l'acquisition vidéo de le modifier pour modifier toutes les 30 secondes (éventuellement) la caméra (par exemple en passant en paramètre de lancement un fichier donnant la liste des caméras, et un délai)..

Dans ce cas, au démarrage, le programme lit le fichier (si il existe), en déduit le nombre de caméras et leurs ports (par exemple, stocke ça dans un tableau, et à chaque expiration du délai se déplace dans le tableau...

fichier :
caméra 1 : port 1
caméra 2 : port 3
.....

dans le prog :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 // lit fichier Cameras[0].port = 1 ; Cameras[1].port = 3 // acquisition ... int num = 0 ; // démarre avec Cameras[0] à t0 port = Cameras[0].port // boucle sur le temps while (t) { acquiert(port); if ( t == (t0 + délai) ) { if ( num == (NB_Cameras-1) ) num = 0 ; else num = num + 1 ; port = Cameras[num].port ; t0 = t ; } }
Pour ce genre de cas c'est ce que moi je ferais. Mais encore une fois je ne suis pas forcément la panacée..

21/02/2007, 21h39
Flophx

Oui, je m'en doute, mais alors, dans quel cas utiliseras-t-on un thread?? (si par exemple on avait une télécommande et qu'on switchait à volonté??
21/02/2007, 22h33
hegros

Citation:

Envoyé par Flophx

Oui, je m'en doute, mais alors, dans quel cas utiliseras-t-on un thread?? (si par exemple on avait une télécommande et qu'on switchait à volonté??

On utilise un thread lorsqu'on a besoin de faire plusieurs traitements en paralléle.

L'exemple le plus basic : Réalisation d'un serveur de socket.

Le thread principal se charge d'attendre les connexions client.Lorsqu'une connexion arrive on crée un thread qui va être chargé de dialoguer avec le client.

Si on décidait que c'est le thread principal qui dialogue avec le client alors toute tentative de connexion d'un nouveau client échouerait.
21/02/2007, 22h55
Flophx

Bien, c'est un peu plus clair à présent...
Mon cas immédiat se résume donc à des processus lourds. En revanche, si par exemple je voulais faire de la télémétrie, dans la mesure où il faudrait "entrelacer" les données capteurs et vidéo afin de les envoyer sur un seul canal, je serais alors obligé de faire un traitement parallèle qui lui nécessiterait un thread??

Voir 40 message(s) de cette discussion en une page