| Les deux révisions précédentes
Révision précédente
|
Dernière révision
Les deux révisions suivantes
|
thread_tableaublanc [2008/10/27 07:28]
tyrtamos |
thread_tableaublanc [2008/10/27 07:46]
tyrtamos |
| Pour le fournisseur des messages, il a fallu le "freiner" un peu, parce que dans les 1ères exécutions, je me suis retrouvé en quelques secondes avec 200000 calculs en attente dans le tableau blanc... Donc, quand la pile atteint 100 messages, il attend qu'elle redescende à 20 pour redémarrer. | Pour le fournisseur des messages, il a fallu le "freiner" un peu, parce que dans les 1ères exécutions, je me suis retrouvé en quelques secondes avec 200000 calculs en attente dans le tableau blanc... Donc, quand la pile atteint 100 messages, il attend qu'elle redescende à 20 pour redémarrer. |
| |
| Dans ce programme, les threads de calcul ne s'arrêtent jamais, ce qui est inhabituels. Quand ils ont terminé un calcul, il cherchent un nouveau message disponible en attente pour le prendre en compte. Dans une première version, j'avais fait en sorte qu'ils se suicident quand l'attente dépassait 5 secondes, mais cela posait le problème d'ajouter de nouveaux threads de calcul en cas de nécessité (taille de la file d'attente). Une autre solution consiste à créer le thread à chaque nouveau calcul, mais il faut alors qu'un thread spécialisé (ou le programme principal) joue le rôle de planificateur (scheduler) pour scruter le tableau blanc et créer le thread. A reprendre ultérieurement. | Dans ce programme, les threads de calcul ne s'arrêtent jamais, ce qui est inhabituel. Quand ils ont terminé un calcul, il cherchent un nouveau message disponible en attente pour le prendre en compte. Dans une première version, j'avais fait en sorte qu'ils se suicident quand l'attente dépassait 5 secondes, mais cela posait le problème d'ajouter de nouveaux threads de calcul en cas de nécessité (taille de la file d'attente). Une autre solution consiste à créer le thread à chaque nouveau calcul, mais il faut alors qu'un thread spécialisé (ou le programme principal) joue le rôle de planificateur (scheduler) pour scruter le tableau blanc et créer le thread. A reprendre ultérieurement. |
| |
| Une subtilité qu'on ne voit pas tout de suite: quand un thread a pris en compte un message, il le déclare "encours" afin que les autres threads ne s'en occupent pas. Mais il faut aussi que le thread enregistre son nom dans le message. Pourquoi? Pour pouvoir retrouver le message dans la pile! En effet, le verrou est relaché avant le calcul, et quand le calcul est terminé, le message a changé d'index dans la pile à cause des autres thread. Pour la même raison, si le message change d'index, il aurait pu lui être affecté un autre résultat par un autre thread. Par contre, la recherche avec le statut "encours" + le nom du thread permet à chaque thread de retrouver son message à coup sûr. | Une subtilité qu'on ne voit pas tout de suite: quand un thread a pris en compte un message, il le déclare "encours" afin que les autres threads ne s'en occupent pas. Mais il faut aussi que le thread enregistre son nom dans le message. Pourquoi? Pour pouvoir retrouver le message dans la pile! En effet, le verrou est relaché avant le calcul, et quand le calcul est terminé, le message a changé d'index dans la pile à cause des autres threads. Pour la même raison, si le message change d'index, il aurait pu lui être affecté un autre résultat par un autre thread. Par contre, la recherche avec le statut "encours" + le nom du thread permet à chaque thread de retrouver son message à coup sûr. |
| |
| Vous voyez comment on utilise le verrou (vtblanc) afin d'éviter que 2 threads puissent intervenir en même temps sur le tableau blanc. Un peu comme sur un vrai tableau blanc avec un seul marqueur: seul celui qui l'a en main peut écrire! | Vous voyez comment on utilise le verrou (vtblanc) afin d'éviter que 2 threads puissent intervenir en même temps sur le tableau blanc. Un peu comme sur un vrai tableau blanc avec un seul marqueur: seul celui qui l'a en main peut écrire! |
