C'est normal puisque tu n'as jamais posé cette question.
En revanche, tu as demandé SI les 2 threads pouvaient communiquer par une socket, et là je t'ai répondu dans mon message #24
beh comment les 2 threads peuvent communiquer ?
je présume que c'est avec des sockets ?
quel est le but de mettre en oeuvre des threads au lieu d'une communication directe sur BUS ?
merci![]()
(re)lire mon message #19quel est le but de mettre en oeuvre des threads
Encore une (dernière) fois: QUEL BUS ?????au lieu d'une communication directe sur BUS ?
Et pour en rajouter sur ce que dit Jack, ce n'est pas l'un ou l'autre et c'est 2 sujets différents.
Sans même parler du fait qu'en lisant le fil, on l'a déjà pas mal expliqué.
Dernière modification par Bluedeep ; 24/02/2017 à 16h09.
Salut,je vais resumer la situation :
nous avons 2 cartes :
carte A sur laquelle tourne un process alpha qui regroupe plusieurs fonctions .
carte B sur laquelle tourne un process beta qui regroupe plusieurs fonctions .
la carte A doit interroger plusieurs cartes de type B , disant B1,B2,B3 ...B10 pour recuperer des donné de manière synchrone (en parallèle ) .
le programme de récupération des donnés de la carte A devrait recuperer toutes les info en temps réel .
donc sur la carte A on devrait avoir un thread, nommé thread A dans le quel le code est inscrit , et qui recoit les demandes de l'utilisateurs (ex. get ) qui permet d'accèder aux donnés des autres cartes B...
chaque carte B devrait aussi avoir un thread B qui recupère les info sur la propre carte B et les renvoie au thread A ??
est ce que c'est logique ?
je suis novice sur les thread!
merci à vous
Tes cartes A, B1,B2,B3.... sont installées comment? quel type de fond de panier? c.a.d. quel type de BUS ?
G64, G96, PC100, VME, etc... etc... ou un BUS PC ? tous ces BUS de type Parallèle
Ou encore tes cartes B1....etc.. sont 'elles installées à des endroits différents ? auquel cas le BUS de communication sera de Type soit USB, CANBUS, PROFIBUS, I2C, Ethernet, FIP, etc...etc... tous ces BUS sont de type Série, Les protocoles de communication sont pas les mêmes.
Dans le premier cas les accès se font par adressage de cartes au travers du fond de panier, dans le second l'adressage se fait dans certains cas avec un jeton. Mais chaque type de Bus série possède son propre protocole.
Pour ce qui est du temps réel, tu dois vérifier les constantes de temps de ton/tes processus, Le bus doit être environs 10 fois plus rapide que la plus petite constante de temps du/des systèmes.
Il faut commencer par dire tous ça si non on peut pas répondre à ta question.
Ceci étant, ici t'es au mauvais endroit pour ta question, les gens ici font du code, regarde chez les électroniciens, ils seront plus à même de répondre à ta question.
Cordialement
Ludwig
Question à 2 balles:
Il y a combien de systèmes qui tournent ? ? ?
Parce que là, on ne sait pas trop, tellement c'est pas clair...
Si tu as 2 systèmes, il te faut une communication qui les relie physiquement.
Si tu as 1 système, tu as le choix des armes das les tuyaux de communications (tcp, udp, ipc, pty, ws...), chaque truc a ses avantages et ses inconvénients... (oui, j'ai même mis le web-socket, je sais, c'est lourd, mais ça n'a pas que des inconvénients...)
Sinon, les threads, c'est bien...
quand on a la flemme ou ne sait pas utiliser les select, poll ou autre epoll...
Jusqu'ici tout va bien...
Ça n'est pas qu'une question de "flemme", comme écrire en C n'est pas plus une question de "flemme d'écrire en assembleur"
D'un point de vue "architecture dynamique", les threads sont un outil intéressant en développement logiciel.
Dans le cas présent, comme cela a été dit, et hormis si les threads tournent tout deux sur le même CPU et dans le même processus (ce qui ne semble pas être le cas), ce ne sont pas des outils de "communication" mais des outils de partage des ressources CPU (temps d'exécution) et mémoire.
J'imagine en revanche que les cartes A et Bn vont communiquer par le biais du bus dont tu ne donnes aucune référence ici.
:'( Plus j'apprends, et plus je mesure mon ignorance
J'avoue, j'étais un peu (beaucoup) polémique...
(qui a dit "comme d'hab" ? ? ?)
C'était pour piquer au vif et réveiller la curiosité sur les autres moyens existants (qui peuvent être assez ch..t à mettre en oeuvre, il faut l'avouer).
Et en effet, ce n'est pas le thread qui ouvre les tuyaux de com, ce sont d'autres outils.
Mais en fait, on ne sait même pas comment est globalement structuré le système en question, donc dur de répondre précisément.
Jusqu'ici tout va bien...