Architecture du processus

$P_{gestion}$ se compose de trois parties distinctes principales relatives respectivement aux protocoles dont il a la charge. Chacun des protocoles exige sa file de message particulière, $P_{gestion}$ reste donc en attente d'un événement sur les files de messages relatives aux protocoles $ISA$ et $MSA$. Mais cette attente ne peut être qu'active ce qui bloquerait le processus sans qu'il puisse surveiller équitablement les deux files.

La solution est venue de l'utilisation de processus légers ou threads. Un tel choix se justifie par le fait que, par rapport à une implémentation processus équivalente, les threads ont une plus grande rapidité de commutation du fait de leur contexte très réduit et surtout parcequ'ils offrent la possibilité de gérer l'ordonnancement et donc la priorité des activités au sein de $P_{gestion}$.
Ainsi, la gestion de chaque file de message se fait "au travers" d'un thread, ce qui permet de paralléliser l'attente d'évènement sur les files des protocoles $ISA$ et $MSA$. La file $NUM$ quant à elle bénéficie aussi d'un thread, mais aucune attente n'est faite. $P_{gestion}$ se contente de vérifier que le nombre de messages⁸ qu'elle contient est toujours supérieur à un minimum fixé à l'avance et la complète en générant de nouveau messages jusqu'à concurrence du nombre nécessaire.