| Les deux révisions précédentes
Révision précédente
Prochaine révision
|
Révision précédente
|
thread_tableaublanc [2008/10/27 07:28]
tyrtamos |
thread_tableaublanc [2008/10/27 07:47]
tyrtamos |
| 2- le tableau blanc est inspiré d'une pile FIFO, c'est à dire d'une file d'attente. Une particularité par rapport à une simple pile FIFO, c'est qu'on peut intervenir à l'intérieur de la pile (pour chercher, lire, modifier et effacer). | 2- le tableau blanc est inspiré d'une pile FIFO, c'est à dire d'une file d'attente. Une particularité par rapport à une simple pile FIFO, c'est qu'on peut intervenir à l'intérieur de la pile (pour chercher, lire, modifier et effacer). |
| |
| 3- l'un des threads, appelé ici le "fournisseur" (classe Fournisseur), va générer des expressions mathématiques à calculer et de les placer dans le tableau blanc sous forme de messages en attente. | 3- l'un des threads, appelé ici le "fournisseur" (classe Fournisseur), va générer des expressions mathématiques à calculer et les placer dans le tableau blanc sous forme de messages en attente. |
| |
| 4- l'un quelconque des 10 threads de calcul, appelés ici les "traiteurs" (classe Traiteur), ayant terminé son calcul précédent, va chercher sur le tableau blanc un message en attente, va le déclarer "encours" avec enregistrement de son nom de thread, va en calculer son expression, va ajouter son résultat au message et le déclarer celui-ci "fini". | 4- l'un quelconque des 10 threads de calcul, appelés ici les "traiteurs" (classe Traiteur), ayant terminé son calcul précédent, va chercher sur le tableau blanc un message en attente, va le déclarer "encours" avec enregistrement de son nom de thread, va en calculer son expression, va ajouter son résultat au message et le déclarer celui-ci "fini". |
| 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! |
