Discussion :

[Flophx]

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.

[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

[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!! )

[Emmanuel Delahaye]

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

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

[souviron34]

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!! )

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

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

me laisse perplexe....

[Flophx]

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

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

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...

[souviron34]

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

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 ?

....




.

[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)....

[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 ?

[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?

[souviron34]

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 .... 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....

[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??

[souviron34]

absolument..

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

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..

[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?

[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.... peut-être que je n'ai pas la bonne solution....

[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)??

[souviron34]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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..

[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é??

[hegros]

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.

[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??