| Les deux révisions précédentes
Révision précédente
|
Prochaine révision
Les deux révisions suivantes
|
thread_tableaublanc [2008/05/08 20:26]
tyrtamos |
thread_tableaublanc [2008/10/27 07:28]
tyrtamos |
| * tous les threads ont accès à tous les messages et ont a priori tous les droits dessus (création, lecture, modification, effacement) | * tous les threads ont accès à tous les messages et ont a priori tous les droits dessus (création, lecture, modification, effacement) |
| |
| Cela n'empêche pas qu'un message puisse être destiné à un thread en particulier, mais il faudra trouver un moyen de codage pour arriver à ce résultat. | Cela n'empêche pas qu'un message puisse être destiné à un thread en particulier, mais il faudra ajouter le code nécessaire pour arriver à ce résultat. |
| |
| J'ai cherché dans les modules existants de Python un moyen de programmer ce tableau blanc, mais je n'ai pas trouvé. Par exemple, dans le module queue, on ne peut pas lire une information sans la retirer de la pile, ce qui ne convient pas ici. | J'ai cherché dans les modules existants de Python un moyen de programmer ce tableau blanc, mais je n'ai pas trouvé. Par exemple, dans le module queue, on ne peut pas lire une information sans la retirer de la pile, ce qui ne convient pas ici. |
| 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 de 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 "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". |
| |
| 5- le programme principal, en plus d'initialiser et de démarrer l'ensemble, va trouver les messages "finis", les extraire, les effacer du tableau blanc, afficher leurs résultats et afficher aussi des statistiques sur le fonctionnement de la machine. | 5- le programme principal, en plus d'initialiser et de démarrer l'ensemble, va trouver les messages "finis", les extraire, les effacer du tableau blanc, afficher leurs résultats et afficher aussi des statistiques sur le fonctionnement de la machine. |
| Quelques commentaires sur le code | Quelques commentaires sur le code |
| |
| 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 descende à 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 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. |
