Communication inter threads avec boost

[MikeLarson]

Bonjour,

J'ai cherché à utiliser boost seulement j'ai une question : comment puis-je faire communiquer 2 threads de telle sorte que le premier envoi une message du type "send:event:toTh8:param:ID'5'", en gros une chaine de caractère?
Au début je pensais utiliser une mémoire partagée avec un mutex pour gérer la lecture/écriture. Seulement j'aimerais pouvoir endormir un thread et que celui-ci ne se réveil que si il recoit un signal, exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
void funcTh1(){
...
...
wait(signal);
...
}
 
void funcTh2(){
...
sen_signal(toTh2, myMessage);
...
}

Je ne sais pas si je me fais comprendre.

En tout cas si un tutaux existe dèja sur mon problème précis je m'excuse pour mon manque de recherche.

Merci d'avance!!!!

[Ekleog]

pthread dispose d'un mécanisme de conditions (cf. un tuto à ce sujet sur ce même site).

Après, tout dépendra de la librairie que tu utilises.

[MikeLarson]

Bonjour, j'utilise toute celle qui sont dans boost.

[MikeLarson]

Do c je n'utilise pas pthread mais plutôt boost::thread et toutes les librairies de boost que je peu avoir ^^

[DonQuiche]

Bonjour.

La mémoire partagée (shared memory) est réservée à la communication inter-processus. Pour de la communication inter-threads, rien de particulier n'est nécessaire puisque tous les threads ont accès à l'intégralité de la mémoire du processus. On pourra par exemple stocker l'info à partager dans une variable statique ou passer un pointeur vers l'emplacement partagé en argument au démarrage du thread.

Concernant la "mise en sommeil jusqu'à ce que...", on utilise des condition variables. Pour Boost, voici l'exemple de la doc officielle. Note l'appel à "cond.wait" dans un thread et "cond.notify_one" dans un autre.

[MikeLarson]

Merci pour la réponse!

Par contre si j'ai bien compris :

mutex mutexLocker;

- Communication entre thread1 et thread 2 :
condition_variable cond1;
void funcTh1(){
unique_lock<boost::mutex> lock(mutexLocker);
...
// Endormissement du thread
cond1.wait(lock);
....

void funcTh2(){
...
// envoi de signal => débloquage de Th1
cond1.notify_one();

Si je veux faire de même entre Th1 et Th3 je créai un autre condition_variable? et/ou un autre mutex? A mon avis je dirais oui.

Merci en tout cas pour l'aide.

Bonne journée.

[DonQuiche]

Envoyé par MikeLarson

Si je veux faire de même entre Th1 et Th3 je créai un autre condition_variable? et/ou un autre mutex? A mon avis je dirais oui.

Si tu utilises une seule variable commune, T2 ou T3 pourront chacun, indépendamment, réveiller T1. C'est le comportement recherché pour un agent par exemple : imagine une file d'impression gérée par un seul thread, T1, qui pourrait recevoir des travaux en file de n'importe quel Tn ; à chaque mise en file d'un thread quelconque on souhaite réveiller T1.

Si en revanche tu utilises deux variables distinctes avec deux appels successifs à wait(), alors T1 n'entrera en activité qu'une fois que T2 et T3 auront tous deux appelé notify_one(). C'est le comportement recherché, par exemple, pour un algorithme de calcul exposant une méthode synchrone Run() et qui diviserait le travail sur plusieurs threads : on souhaite que Run() ne retourne qu'une fois que tous les threads auront terminé.

Bémol pour ce dernier cas : si T1 attend d'abord une variable X puis une variable Y, le scénario "notify Y ; reset Y ; notify X" laissera T1 en attente de Y comme si celui-ci n'avait jamais été notifié. Boost propose peut-être une méthode pour attendre plusieurs variables afin d'éviter ce problème.

[MikeLarson]

Oui je comprend tout à fait, merci pour ces précisions.
Je me suis pas mal entraîné ce matin et j'arrive à gérer les "cond" pour synchroniser les threads comme je le souhaite.

Maintenant j'aurais une autre question ^^, j'aimerais pouvoir gérer la communication entre plusieurs thread un peu comme Ivy, c'est à dire que soit :
- Chaque thread s'abonnerait à un type de message qui quand celui-ci le recoit il se réveil et lance une fonction associée.
- Soit un thread envoit un message à un autre qui se réveillera et lancera une fonction.

Par exemple : Th1 send(toTh2, "requeteD'ecriture:message="coucou");
Th2 qui etait endormie recoit le message et traite le demande.

Pour cela je pensais faire un cond.wait(lock) et faire une structure partagée où chaque thread ira lire dans sa boite au lettre dédiée le message, mais je préfére demander avant si il n'existe pas déjà une sous librairie de boost permettant de le faire, je n'ai pas trouvé.

Encore merci en tout cas!! Je découvre boost et c'est pas évident ^^

[DonQuiche]

Malheureusement je ne connais pas assez Boost pour te répondre, je suis moi-même en train de passer en revue les différents frameworks C++ pour en choisir un qui répond à mes besoins. Cela dit, dans mes recherches j'ai repéré deux choses qui semblent convenir :
* Boost.MPI : Message Passing Interface. En général c'est plutôt pour de la communication inter-processus sur des architectures massivement distribuées mais tu peux peut-être réutiliser certains éléments.
* Le IOService ASIO, qui fournirait une brique de base.

[Ekleog]

MPI et IO sont, de mémoire, plutôt faits pour une infrastructure à plusieurs ordinateurs.
Donc probablement peu efficaces dans la gestion du cache processeur.

Une solution à la main serait probablement plus rapide - et surtout pas nécessairement très longue à écrire : une classe qui stocke les abonnements et des pointeurs vers les threads (chaque thread donnant accès à sa condition et à sa "boite aux lettres", ainsi qu'au mutex de celle-ci), et qui à la réception d'un message (mutex ici), l'envoie à chaque thread (mutex-boite aux lettres ici), puis réveille chaque thread en déclenchant leur condition.
C'est long à expliquer, mais ça se fait en ajoutant une classe, quelques variables et une trentaine de lignes d'envoi de message (chiffres pris à la louche).

[DonQuiche]

Effectivement, je confirme que toute la partie "agent" s'écrit relativement bien. Entre une heure et une journée selon le niveau d'expérience avec les problèmes de ce genre pour l'écriture, le test et le déboguage.

[MikeLarson]

Oui effectivement je suis partie sur le développement de ma propre "librairie" de gestion de com inter-thread, avec une structure comprenant un mutex, une condition et l'instance de ma donnée. Un thread initial va créer un poiteur partagé "shared_ptr" de cet classe pour chaque thread (une boite aux lettre par personne) et transmettra ces pointeurs à chaque thread qu'il créera, ainsi chaque thread pourra utiliser les méthodes de com avec chaque thread sans se soucier des mutex et des conditions, ce sera transparent.

Cette idée me semble bonne même si j'ai un peu tendance à m'embrouiller pour le moment, je découvre boost et j'aurais bien aimé m'en passer ^^
En tout cas merci pour votre aide, je vous souhaite une bonne soirée!

[Ekleog]

Justement, c'est une bonne chose : après, tu sauras te servir du boost pour les parties sur le threading.

[DonQuiche]

Envoyé par Ekleog

Justement, c'est une bonne chose : après, tu sauras te servir du boost pour les parties sur le threading.

Dommage que cette connaissance devienne obsolète d'ici six mois à un an avec C11.

[Ekleog]

Sauf avec un :%s/boost::/std:: !

[jblecanard]

Envoyé par Ekleog

Sauf avec un :%s/boost::/std:: !

C'est clair, ce sera pas complètement obsolète comme connaissances, même si des changements sont apportés.

[MikeLarson]

Oui j'espère que ça ne me servira pas à rien, en tout cas j'ai pas le choix pour l'instant ^^

J'ai développé mes classes seulement je rencontre un problème (encore je sais!) qui est le suivant :

THA attend un reveil,
THB se lance et reveil THA,
THA se réveil, travail et est censé réveillé THB,
seulement avec les con.notify_one() le thread réveillé s'execute directement, du coup le thread qui éveil l'autre (ici B) n'a pas le temps d'aller faire son wait....

Peut être je me complique la vie mais j'aimerais éviter de faire des attentes active pour pallier à ce problème....

Des idées? ^^

[DonQuiche]

D'abord, pourquoi B doit-il être mis en sommeil ? A te lire j'ai l'impression que lorsque A est actif, B doit dormir et réciproquement. Si c'est le cas, pourquoi utiliser du multithread ?

Ensuite, est-ce un problème si B n'a pas le temps d'attendre wait ? Même si notify_one a été fait avant wait(), le wait() sera correctement zappé.