thread, mutex, etc

Heuu en fait en regardant de plus pres j'ai modifié mon run ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

virtual void run() { while(true) {   _mutex->lock(); _condition->wait(_mutex);   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

et j'ai ajouté dans mes acces en écriture situé dans les threads un signal()... certainement le signal qu'attendait mon wait()...

Bref ça a l'air de tourner comme il faut à présent.
Merci.

Je pense que j'en ai terminé avec les threads, faute de quoi je viendrai dépoussierer le topic.

Merci à tous de votre aide.

Il y a une technique spécifique pour l'utilisation des variables de condition. Voila l'algo:

Code:

---

1 2 3 4 5 6

mutex.lock(); while(is_it_good_to_continue()) { condition.wait(); } operation(); mutex.unlock();

---

Comme le mode de fonctionnement exact d'une variable de condition est soumis à interprétation (si je fais un signal puis juste après un wait je suis bloqué ou pas?) il vaut mieux se méfier. Cet algo permet de gérer tous les cas de figure, même si un signal() est effectué quand il n'aurait pas du.

Par contre je comprends moyennement ta méthode broadcast. En admettant que ce soit un autre nom pour l'opération signal(), à quoi cela peut-il servir si le wait() et le signal() sont effectués par le même thread?

le wait() et le signal ne sont pas effectués par le meme thread... d'où ce broadcast() qui est un "signal()" à tous les threads en attente...

Citation:

---

Envoyé par Ange_blond

le wait() et le signal ne sont pas effectués par le meme thread... d'où ce broadcast() qui est un "signal()" à tous les threads en attente...

---

Donc le broacast c'est un signal... Dans les morceaux de code que tu nous as collé, c'est le même thread qui fait le wait et broadcast, ça n'a pas de sens. Ce qu'on désire quand on utilise une variable de condition c'est qu'un thread se retrouve bloqué et qu'un autre le libère.
Tu n'as peut être pas collé tout ton code. Ce qu'il serait intéressant si tu veux qu'on puisse commenter ton code serait que tu nous désignes précisément les morceaux de code liés aux threads "lecteurs" et aux threads "écrivains" (ça n'a pas d'importance de savoir lequel initialise une ressource à la base ou lequel est le thread principal) ainsi que le nombre de ces threads des deux cotés (un ou plusieurs?).

heuu, he bien selon moi tout marche bien là, mais dans un soucis de comprendre tout oui voilà :

Sur ma pile : Unique thread dont le run() est :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

virtual void run() { while(true) {   _mutex->lock(); _condition->wait(_mutex);   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

Qui accedent à la pile : plus de 150 threads (nombre variable) dont le code ressemble à :

Code:

---

1 2 3 4 5 6 7 8 9 10

[...] _mutex->lock();   addonstack(....);   _mutex->unlock();   _condition->signal(); [...]

---

Voilou.

Remarque sans rapport direct avec ta question :
Je ne sais pas ce que tu as comme machine, mais une appli de plus de 150 threads sur une architecture classique n'est probablement pas optimale, et va passer plein de temps à basculer d'un thread à l'autre.

Ha, la alors ça me semble correct.
Néanmoins il me semble important de modifier le code de ton lecteur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

virtual void run() { while(true) {   _mutex->lock(); while(stack_is_empty()) { _condition->wait(_mutex); }   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

Une variable de condition n'est pas à proprement parler une condition. C'est un dispositif qui permet de bloquer un thread jusqu'à ce qu'un autre décide de lui signaler que l'état d'une condition a potentiellement changé.
Dans les tests que tu as effectué, tu as peut être eu de la chance mais selon moi ce n'est pas sensé fonctionner comme ça.
Imaginons un cas comme un autre : un thread écrivain ajoute un seul objet à la liste et fait un signal, par la suite plus aucun nouvel objet ne sera ajouté. Ensuite ton thread lecteur fait un wait, il peut donc se retrouver bloqué éternellement suivant le comportement de l'api de thread utilisé, puisque plus aucun autre signal n'aura lieux. Pourtant il y a une donnée dans la liste -> donc c'est une erreur.

Citation:

---

Envoyé par zais_ethael

Imaginons un cas comme un autre : un thread écrivain ajoute un seul objet à la liste et fait un signal, par la suite plus aucun nouvel objet ne sera ajouté. Ensuite ton thread lecteur fait un wait, il peut donc se retrouver bloqué éternellement suivant le comportement de l'api de thread utilisé, puisque plus aucun autre signal n'aura lieux. Pourtant il y a une donnée dans la liste -> donc c'est une erreur.

---

Certes, j'ai bien remarqué la chose, mais dans l'utilisation normale du programme, la pile ne risque pas de refroidir beaucoup... mais je vais néanmoins corriger ça pour que ce soit clean.

Merci

Citation:

---

Envoyé par JolyLoic

Je ne sais pas ce que tu as comme machine, mais une appli de plus de 150 threads sur une architecture classique n'est probablement pas optimale, et va passer plein de temps à basculer d'un thread à l'autre

---

La base des 150 thread avait déjà été mis en place avant que je commence à m'interesser à la synchro... cependant ils sont legers et sont aussi nombreux pour pouvoir lancer des telechargements simultanés, tout simplement... pas de soucis sur ma machine (puissante) ça tourne plutot bien :-)

Merci à tous pour votre aide et vos conseils :D