Qu'est-ce qu'un pool de threads?

Comment implémenterait-on un pool de threads? J'ai lu sur wikipedia pour "threadpool" mais je ne comprends toujours pas ce qu'il faut faire pour résoudre cette question (peut-être parce que je n'avais pas bien compris ce qu'est un pool de threads en termes simples).

Quelqu'un peut-il m'expliquer en anglais clair ce qu'est un threadpool et comment pourrait-on répondre à cette question?

Un pool de threads est un groupe de threads inactifs pré-instanciés qui sont prêts à recevoir du travail. Celles-ci sont préférables à l'instanciation de nouveaux threads pour chaque tâche lorsqu'il y a un grand nombre de tâches courtes à effectuer plutôt qu'un petit nombre de tâches longues. Cela évite de devoir générer un nombre important de threads.

L'implémentation varie en fonction de l'environnement, mais en termes simples, vous avez besoin des éléments suivants:

• Un moyen de créer des threads et de les maintenir dans un état inactif. Ceci peut être accompli en faisant en sorte que chaque thread attende à une barrière jusqu'à ce que la piscine lui donne le travail. (Cela pourrait aussi être fait avec les mutex.)
• Conteneur destiné à stocker les threads créés, tels qu'une file d'attente ou toute autre structure permettant d'ajouter un thread au pool et d'en extraire un.
• Une interface standard ou une classe abstraite pour les threads à utiliser pour effectuer le travail. Il peut s'agir d'une classe abstraite appelée Taskavec une execute()méthode qui effectue le travail, puis retourne.

Lorsque le pool de threads est créé, il instancie un certain nombre de threads à rendre disponibles ou en crée de nouveaux au besoin, en fonction des besoins de l'implémentation.

Lorsque le pool est remis à un Task, il prend un fil du conteneur (ou attend qu’il en reste un disponible si le conteneur est vide), le lui remet Tasket rencontre la barrière. Cela provoque la reprise de l'exécution du thread inactif, en invoquant la execute()méthode qui Tasklui a été donnée. Une fois l'exécution terminée, le fil se remet au pool pour être placé dans le conteneur en vue de sa réutilisation et rencontre ensuite sa barrière, se mettant en veille jusqu'à ce que le cycle se répète.

Le pool de threads est une collection de threads gérés généralement organisés dans une file d'attente, qui exécute les tâches de la file d'attente.

La création d'un nouvel objet thread chaque fois que vous avez besoin d'exécuter quelque chose de manière asynchrone est coûteuse. Dans un pool de threads, vous ajoutez simplement les tâches que vous souhaitez exécuter de manière asynchrone à la file d'attente des tâches et le pool de threads s'occupe de l'affectation d'un thread disponible, le cas échéant, pour la tâche correspondante. Dès que la tâche est terminée, le thread maintenant disponible demande une autre tâche (en supposant qu'il en reste).

Le pool de threads vous aide à éviter de créer ou de détruire plus de threads que ce qui serait vraiment nécessaire.

Je commencerais par créer une classe avec une file de threads et une file de tâches. Puis implémentez une méthode qui ajoute une tâche à la file d'attente et continue à partir de là. Bien entendu, vous devez également permettre de définir le nombre maximal de threads autorisés dans un pool de threads.

Dans une application multithread, le pool de threads est un "pool de threads disponibles" pouvant être utilisé par votre application. Habituellement, par exemple .NET, tout est géré, vous n'avez donc qu'à assigner des tâches et lorsqu'un thread est libre, il va l'exécuter. Donc, pour implémenter un pool de threads, je m'attendrais à créer un concept dans lequel les tâches sont automatiquement prises par des threads libres sans création explicite de thread pour chaque tâche.

Exemple de vie réelle;

1. Installation: système d'exploitation
2. Sections: Applications
3. Personnes: Fils

Vous avez une installation là-bas 12 personnes travaillent. Il y a 3 sections de cette installation. Cuisine, toilettes et sécurité. Si vous n'utilisez pas la technique de pool de threads, voici comment cela fonctionne: Les 12 personnes se tiendront dans une salle de réunion, si de nouveaux clients arrivent et demandent des tâches, vous séparez les personnes en groupes et les envoyez pour qu'elles fassent leur travail. et revenez à la salle de réunion. Mais avant qu’ils n’assument leurs fonctions, il y a une phase de préparation. Ils doivent porter l'uniforme approprié, équiper certains appareils et se rendre à cette section, terminer leur travail et revenir. Ainsi, une fois à la fin de leur travail (le fil se termine), ils doivent retourner dans la salle de réunion, se déshabiller, prendre leur équipement et attendre leur prochain travail. Celles-ci font référence à la création d'un contexte de thread, à son allocation de mémoire et à des informations de suivi par système d'exploitation.

Si vous utilisez la mise en commun des threads, tôt le matin, vous affecterez 6 personnes à la cuisine, 2 personnes aux toilettes et 4 personnes à la sécurité. Ainsi, ils ne feront leur préparation qu'une fois par jour. Même s'il n'y a pas de clients à la cuisine, ces 4 personnes seront là, au ralenti, pour toutes les tâches à venir. Ils n'ont pas besoin de retourner dans la salle de réunion jusqu'à la fermeture de la cuisine (l'application se termine). Ces 4 personnes sont dans la piscine de l'application Cuisine et sont prêtes à vous servir rapidement. Mais, vous ne pouvez pas promettre qu'ils travaillent toute la journée, car la cuisine peut devenir inutilisée de temps en temps. La même logique s'applique aux toilettes et à la sécurité.

Dans le premier scénario, vous ne perdez pas de thread pour une tâche quelconque, MAIS il faudra beaucoup de temps pour préparer chaque thread pour chaque tâche. Dans un second temps, vous préparez les threads à l'avance. Vous ne pouvez donc pas garantir que vous utiliserez tous les threads pour toutes les tâches, mais le système d'exploitation optimise généralement son fonctionnement, de sorte que vous pouvez vous y fier en toute sécurité.