Bonjour à tous ,
Je me retrouve face à une difficulté de comprendre les threads :
voici le problème :
Nous avons 2 process A, B
Le process A crée une thread lorsqu'il recoit un ordre qui doit récupèrer des info qui tournent sur le process B (donnée de température par exemple ) .
le process B doit il créer une thread pour communiquer avec le thread du process A ?
A quoi sert tout cela ? (les threads !!)
Merci de votre aide .
Des threads qui tournent sur quelle machine ? avec quel O.S. ?
J'aime pas le Grec
Il est impossible de répondre à cette question dans l'absolu. Par défaut, la réponse est non.Envoyé par Linuxman99
A plein de choses mais principalement à faire fonctionner des choses en parallèle tout en partageant la mémoire ce qui permet d'échanger rapidement des données. C'est un modèle de parallélisme.
Bonsoir
si c'est du LINUX ou Unix il vaudrait mieux faire transférer le fil de discussion dans le bon forum dédié au software
Cordialement
Faim dans le monde. Ne laissez de contributeur "sur leur faim", informez nous
sur du linux embarqué
sur une carte avec un linux embarqué
Non, les threads appartenant à leur processus créateur, il ne pourront pas communiquer car ne possédant rien en commun.le process B doit il créer une thread pour communiquer avec le thread du process A ?
Pour faire communiquer 2 processus, on utilise les IPC qui sont faits pour cela (d'où leur nom).
Bonsoir,
Attention, sous Linux en tout cas, on distingue les processus legers (thread) des processus lourds...
Les processus lourds sont bien distincts, mais les "legers" partage tout leur contexte dont les données et le tas (heap) hors la pile (stack).
Il y est donc possible de les faire communiquer sans ipc mais veillant à bien "verrouiller" les ressources.
D'après les questions je ne sais de type de processus il s'agit, notant bien que dans le cas de processus dits lourd, le terme de thread est un abus de langage.
Bien entendu, mais je répondais précisément à SA question, à savoir que les 2 threads appartenaient chacun à un processus distinct.
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
tu veux dire les faire communiquer dans le même process ou faire communiquer un thread du process A avec un autre thread du process B ??
Pourquoi introduire cette ambiguité sémantique ? Quelque soit le système considéré (Linux, Windows, voire sans doute Android), les notions de process, threads et fiber (à confirmer dans ce dernier cas) sont parfaitement univoques. Donc que vient de faire ici cette salade de process "lourds" et "légers"
Pour faire communiquer deux threads, il faut impérativement qu'ils cohabitent sur le même CPU, et dans le même processus.
D'après ta description, ce n'est clairement pas le cas.
Quel(s) moyen(s) de communication dispose-tu entre les cartes B et la carte A ? (l'architecture en thread me semble un point annexe de ta problématiquement de collecte des mesures des capteurs des cartes B).
Dernière modification par Philou67 ; 24/02/2017 à 10h30.
:'( Plus j'apprends, et plus je mesure mon ignorance
Dans l'interprétation la plus littérale de la question, en effet.
Mais on peut aussi voir les choses autrement : on a 2 process qui doivent communiquer via un mécanisme classique (socket, queue, lecture/écriture de fichier, pipe...) et chacun d'entre eux a dédié un thread à la gestion de cette communication.`
C'est ce qui est assez courant actuellement.
C'est ce que j'avais en tête dans ma 1ère réponse mais si la question est purement scolaire et qu'elle consiste à vérifier qu'un étudiant a bien compris la différence entre thread et process, alors c'est effectivement ta réponse et celle de Jack qui sont pertinentes.
Oui, je trouve aussi que ce n'était pas nécessaire.
On peut encore compliquer la chose si on sait que linux crée un processus pour chaque thread
Pour en revenir au problème, thread ou pas thread, les 2 processus s'exécutant sur 2 machines séparées, les sockets me semble en effet un bon candidat. Mais on peut envisager aussi des liaisons séries: RS485, CAN, I2C puisque tu parles de temps réel et que les temps de communication avec ces liaisons sont déterministes, ce qui n'est pas le cas d'ethernet.
Je ne comprends pas; si tu n'utilises pas le CSMA/CD, en quoi les temps de propagation sur la couche 802.3 sont-ils non déterministes ?
Temps réel veut dire qu'on connait le temps de réponse du système face à une requête .
par contre , ça sert à quoi l'utilisation de threads dans le contexte de récupération de resultats de capteur , je ne comprend pas trop l'utilité !!
merci
Mince, je ne sais pas si j'ai les armes pour entrer dans les spécificités de la norme, mais CSMA/CD ne fait-il pas partie intégrante de la 802.3?.
C'est toi qui a parlé d'utiliser un thread. Pour l'utilité, on peut considérer que la récupération des données peut être une tâche qui n'a pas à interférer avec d'autres tâches du programme. On délègue donc cette tâche à un thread.
vous avez parlé de bus de données , quelle est la difference avec l'implementation de threads !!
je suis confus
dans le cas évoqué :
le bus est connecté directement entre la carte A et la carte B , alors que le thread A fait partie du process A dans lequel on implémente une fonction de demande de récupération de données sur thread B du process B qui tourne sur la carte B dans lequel on implemente une fonction de récupération de donnée de capteur ?
Est ce que cela vous semble une bonne logique ?
Merci
Normal que tu sois confus vu que tu distilles les informations au lieu de présenter un vrai cahier des charges et l'architecture exacte de ton système.je suis confus
aucun rapport entre les 2 qui n'ont pas à être comparés.vous avez parlé de bus de données , quelle est la difference avec l'implementation de threads !!
Voilà, le problème: on apprend tout d'un coup que les 2 cartes sont connectées par un bus. Mais quel bus? Combien faudra-t-il de messages encore pour avoir toutes les information ?dans le cas évoqué :
le bus est connecté directement entre la carte A et la carte B
Pour compléter, j'ai trouvé un article intéressant sur Ethernet et temps réel: https://www.ccontrols.com/pdf/Extv5n3.pdf
c'est quoi la difference d'implementation entre les 2 methodes ? Bus et Threads ?
cela s'implemente dans quelle partie du soft ? hard ?
est ce que le thread peut utiliser une socket pour parler avec un 2threads d'un autre process ?
merci
Comme dit plus haut, aucun rapport: Le bus, c'est du hardware et le thread du software.c'est quoi la difference d'implementation entre les 2 methodes ? Bus et Threads ?
ouiest ce que le thread peut utiliser une socket pour parler avec un 2threads d'un autre process ?
Pas en full duplex. Le CSMA/CD est une vieille verrue qui n'a de sens que pour les liaisons multipoint; en pratique depuis la disparition des réseaux coax (10Base-2 et 10Base-5), cela ne concerne que les hub qui ne sont plus non plus vraiment à la mode depuis une bonne quinzaine d'années).
Ok, mais maîtrise-t-on dans ce cas le temps que les switches mettent pour aiguiller les paquets?
Merci;intéressant même si daté (2004).
La réponse à la page 3 de l'article que tu as mis en lien
Impossible de copie/coller le paragraphe considéré.
Dernière modification par Bluedeep ; 24/02/2017 à 14h40.
oui, les problème de collision sont évités, mais pour autant les temps sont-ils garantis. L'article (un peu daté il est vrai), parle alors de 802.1 pour introduire des notions de priorité par exemple.
mais j'ai pas une réponse à ma question !
comment 2 threads peuvent il communiquer ensemble ?
!
