Il est utile de nommer les threads afin de pouvoir déterminer quels threads font quoi à des fins de diagnostic et de débogage.
Existe-t-il une convention particulière de dénomination des threads dans une application fortement multithreadée qui fonctionne mieux qu'une autre ? Y a-t-il des directives ? Quel type d'information doit entrer dans le nom d'un thread ? Qu'avez-vous appris sur la façon de nommer vos threads qui pourrait être utile aux autres ?
À ma connaissance, il n'y a pas de norme. Au fil du temps, j'ai trouvé ces directives utiles :
Utilisez des noms courts car ils ne rendent pas les lignes d'un fichier journal trop longues.
Créez des noms dont la partie importante se trouve au début. Les visualiseurs de journaux dans une interface utilisateur graphique ont tendance à avoir des tableaux avec des colonnes, et la colonne des fils est généralement petite ou sera rendue petite par vous pour lire tout le reste.
N'utilisez pas le mot "fil" dans le nom du fil, car cela est évident.
rendre les noms des fils facilement repérables par grep. Évitez les noms de fils à consonance similaire
si vous avez plusieurs threads de même nature, énumérez-les avec des ID qui sont uniques à une exécution de l'application ou à un fichier journal, selon ce qui convient le mieux à vos habitudes de journalisation.
Évitez les généralisations comme "WorkerThread" (comment nommer les 5 prochains threads de travail ?), "GUIThread" (quelle interface graphique ? est-ce pour une seule fenêtre ? pour tout ?) ou "Calculation" (que calcule-t-il ?).
si vous avez un groupe de test qui utilise les noms de threads pour parcourir les fichiers journaux de votre application, ne renommez pas vos threads après un certain temps. Vos testeurs vous détesteront pour avoir fait cela. Les noms de threads dans les applications bien testées doivent être là pour rester.
lorsque vous avez des threads qui gèrent une connexion réseau, essayez d'inclure l'adresse réseau cible dans le nom du thread (par exemple channel_123.212.123.3). N'oubliez pas l'énumération s'il y a plusieurs connexions au même hôte.
Si vous avez plusieurs threads et que vous avez oublié d'en nommer un, votre mécanisme de journalisation doit fournir un ID de thread unique à la place (spécifique à l'API, par exemple en appelant pthread_self()).
Bien que la réponse de Thorsten soit la plus complète, vous pouvez regarder comment Tomcat nomme ses Threads. J'ai trouvé cela utile. Nous exécutions plusieurs threads avec un planificateur de quartz et la plupart des règles de dénomination suggérées par Thorsten étaient utiles.
Allez-vous utiliser une piscine Thread ? Si oui, cela réduira les chances d'ajouter des méta-informations plus utiles. Dans le cas contraire, la quantité d'informations utiles est illimitée.
Nommer les fils est utile et vous devriez suivre une convention de dénomination comme pour toute autre chose, qu'il s'agisse de variables, de méthodes ou de classes. Nommez-les en fonction de ce qu'ils font et soyez succinct. Si vous rencontrez un jour un problème qui nécessite un thread dump, il sera agréable de regarder le nom et de savoir où chercher le problème dans votre code plutôt que d'examiner les traces de pile et de deviner.
La seule différence est que s'il y a plusieurs threads du même type, il faut vraiment ajouter un index quelconque car les noms de threads doivent être uniques pour satisfaire certaines API. Cela peut également aider à la journalisation si vous montrez le nom du thread pour savoir comment votre application se comporte lorsque l'exécution partielle se produit sur différents threads.
Hmmm... Dans les applications fortement multi-threadées que j'ai écrites, j'ai généralement eu plusieurs threads exécutant la même fonction, donc je ne suis pas sûr que nommer les threads soit très utile dans ce scénario. Cela dit, j'ai attribué à chaque thread un ID entier qui était imprimé dans les messages de journal générés par le thread pour faciliter le débogage.
Pour les autres applications qui avaient des threads avec des tâches uniques dédiées, oui, je les ai nommés de manière descriptive... mais je ne l'ai pas fait parce que c'était une application threadée, je l'ai fait parce que c'est une bonne pratique de codage de le faire.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
