Quel est le concept de mise en œuvre de fil-piscine (en C avec l'aide de Pthreads)? Comment un thread peut-il être affecté à l'exécution de la piscine de thread?
3 Réponses :
Un fil-piscine est une collection d'un nombre fixe de filets créé sur le démarrage de l'application. Les threads s'assoient ensuite en attente des demandes de venir à eux, généralement via une file d'attente contrôlée par un sémaphore. Lorsqu'une demande est faite et qu'il y a au moins un fil en attente, le fil est réveillé, desservent la demande et remonte à l'attente du sémaphore. Si aucun threads n'est disponible, demande la file d'attente jusqu'à ce que l'une.
Le fil-piscines est un moyen généralement plus efficace de gérer des ressources que de simplement commencer un nouveau fil pour chaque demande. Cependant, certaines architectures permettent de créer de nouveaux threads et d'ajouter au pool car l'application est exécutée, en fonction du chargement de la demande.
Ajout à la réponse d'Anon J'aimerais mentionner qu'il existe des piscines de fil fixe qui ont fixé des nombres de fil en cours d'exécution; Les piscines de fil de mise en cache qui peuvent se développer de manière dynamique puis diminuer lorsqu'aucun travail n'est disponible; Les piscines de fil dynamiques peuvent également être liées par nombre maximal de fils et / ou de longueur maximale de la file d'attente de travail. Je ne pense pas qu'il y ait une terminologie définie pour ce type de choses et que l'on rencontre rarement des TP non fixées écrits en C mais au moins on devrait savoir que la TP fixe n'est pas la seule sorte là-bas.
Pour clarifier quelque chose dans les réponses précédentes:
La raison que l'instanciation de plus en plus de threads conduit à l'inefficacité est temps de commutation de contexte . Le système d'exploitation passe périodiquement un thread pour un autre sur le processeur. Cela implique d'économiser l'état d'un fil et de charger l'état d'un autre thread de la mémoire, de sorte qu'il prend du temps non négligeable, n ms, par commutateur de contexte.
Par exemple, si vous avez 10 threads, le contexte de commutation TICTX 10 * N MS. Si vous avez 1000 threads, c'est 1000 * N MS. Comme le nombre de threads simultanés augmente, le passage au contexte commence à submerger toute efficacité dérivée de multithreading. Votre application a une tache douce en termes de meilleur nombre de discussions. Une fois que vous avez déterminé ce nombre sucré par expérimentation, vous pouvez définir votre taille de piscine de fil Max sur ce nombre de threads, obtenant ainsi une efficacité maximale de multithreading.
Il est peu probable qu'il faudrait même jusqu'à 1 ms vers le basculement de contexte, généralement ceux-ci sont plus dans les limites des États-Unis. Tout le reste est très bien cependant.
Qui a dit N était un entier et qui a dit que c'était> = 1?
L'utilisation des unités MS suggère que le moment sera de l'ordre de la SP. Je crois que la plupart des gens qui lisent votre réponse ne pensaient pas que le temps de commutation de contexte était autour de 1 US.