Comme vous avez pu le lire, le modèle se compose de 4 composants: ThreadPool, HandleSet, Handle, ConcreteEventHandler (implémente l'interface EventHandler).
Vous pouvez l'imaginer comme une station de taxi la nuit, où tous les conducteurs dorment sauf un, le chef. Le ThreadPool est une station gérant de nombreux threads - cabines.
Le leader attend un événement d'E/S sur le HandleSet, comme la manière dont un pilote attend un client. Quand un client arrive (sous la forme d'un Handle identifiant l'événement IO), le conducteur leader réveille un autre conducteur pour être le prochain leader et répond à la demande de son passager. Pendant qu'il conduit le client à l'adresse donnée (en appelant ConcreteEventHandler et en lui remettant Handle), le prochain leader peut desservir simultanément un autre passager. Lorsqu'un conducteur a terminé, il ramène son taxi à la gare et s'endort si la station n'est pas vide. Sinon, il devient le leader.
Les avantages de cette configuration sont les suivants:
- pas de communication entre les fils sont nécessaires, aucune synchronisation, ni mémoire partagée (pas de serrures, mutex) sont nécessaires.
- plus ConcreteEventHandlers peuvent être ajoutés sans affecter les autres EventHandler
- réduit le temps d'attente en raison des multiples threads
Les inconvénients sont les suivants:
- réseau complexe
- IO peut être goulot d'étranglement
+1 très bonne description. thead - cab driver, threadpool - station, événement - client, ... –
Vous dites: "aucune communication entre les threads n'est nécessaire". Ce n'est pas vrai, il y a une communication entre les threads: il y a des handovers au thread suivant et il y a aussi un pool de threads en attente qui doit être synchronisé. – Michael
+1 très bonne description. J'ai lu ceci en cours de lecture à ce sujet et j'ai compris cela au lieu d'une explication générale. – Kalle