Conventions de dénomination pour les threads?

Question

Il est utile de nommer les threads afin que l'on puisse trier les threads qui font quoi à des fins de diagnostic et de débogage.

Existe-t-il une convention de dénomination particulière pour les threads dans une application fortement multi-thread qui fonctionne mieux qu'une autre? Des lignes directrices? Quel genre d'information devrait entrer dans le nom d'un fil? Qu'avez-vous appris sur le fait de nommer vos discussions qui pourraient être utiles aux autres?

Answer 1

À ma connaissance, il n'y a pas de norme. Au fil du temps que j'ai trouvé ces lignes directrices pour être utile:

• Utilisez des noms courts parce qu'ils ne font pas les lignes dans un fichier journal trop longtemps.

• Créez des noms où la partie importante est au début. Les visionneuses de journaux dans une interface utilisateur graphique ont tendance à avoir des tables avec des colonnes, et la colonne des threads est généralement petite ou sera réduite par vous pour lire tout le reste. N'utilisez pas le mot "thread" dans le nom du thread car c'est évident.

• rendre les noms de thread facilement grep-able. Si vous avez plusieurs threads de même nature, identifiez-les avec des ID uniques à une exécution de l'application ou un fichier journal, selon vos habitudes de journalisation.

• évitez les généralisations telles que "WorkerThread" (comment nommez-vous les 5 prochaines threads de travail?), "GUIThread" (quelle GUI est-ce pour une fenêtre? Pour tout?) Ou "Calcul" ?).

• Si vous avez un groupe de tests qui utilise des noms de threads pour grep les fichiers journaux de votre application, ne renommez pas vos threads après un certain temps. Vos testeurs vous détesteront de le faire. Les noms de thread dans des applications bien testées devraient ê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). Ne pas oublier l'énumération mais s'il y a plusieurs connexions au même hôte.

Si vous avez beaucoup de fils et oublié de nommer un, votre mécanisme de journal doit sortir un fil ID unique à la place (spécifique API, par exemple en appelant pthread_self())

Answer 2

Hmmm ... Dans les applications fortement multi-threads 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 le nommage des threads est très utile dans ce scénario. Cela dit, j'ai assigné à chaque thread un identifiant entier qui était imprimé dans les messages de log générés par le thread pour faciliter le débogage.

Pour d'autres applications qui avaient des threads avec des tâches uniques dédiées, oui je les ai nommées de façon descriptive ... mais je ne l'ai pas fait parce que c'était une application threadée, je l'ai fait car c'est une bonne pratique à faire alors.

Answer 3

J'ai tendance à aborder les threads de nommage de la même manière que les méthodes de nommage ou les variables. Choisissez quelque chose qui décrit de façon concise le processus dont le thread est responsable. Je ne pense pas qu'il y ait beaucoup d'informations supplémentaires que vous pouvez ou devriez mettre dans un nom de thread. Expressif mais laconique est l'objectif principal. La seule convention peut être d'ajouter un suffixe incrémenté aux threads qui font partie d'un pool.

Answer 4

threads Naming est utile et vous devrait suivre une convention de nommage qui serait pour toute autre chose, que ce soit des variables, des méthodes ou des classes. Nommez-les en fonction de ce qu'ils font et soyez concis. Si jamais vous rencontrez un problème qui nécessite un vidage de threads, il sera bon de regarder le nom et de savoir où chercher votre code plutôt que d'examiner les traces de pile et les devinettes. La seule différence est que s'il y a plusieurs threads du même type, vous devriez vraiment ajouter un index quelconque car les noms de threads devraient être uniques pour satisfaire certaines APIs. Cela peut aussi aider avec la journalisation si vous montrez le nom du thread pour savoir comment votre application se comporte avec l'exécution partielle se produisant sur différents threads.

Answer 5

Alors que la réponse de Thorsten est la plus complète, vous pouvez regarder comment Tomcat nomme ses Threads. J'ai trouvé cela utile. Nous avons exécuté plusieurs threads avec un planificateur de quartz et plusieurs des règles de dénomination que Thorsten suggère étaient utiles.

Allez-vous utiliser un pool de threads? Si oui, cela réduira les chances que vous puissiez ajouter plus de méta-informations utiles. Sinon, le ciel est la limite à combien d'informations utiles vous pouvez avoir.

Answer 6

Qu'en est-:..

[namespace] [classe] [. Classe ...] [Méthode] [thread courant]?

Vous avez donc les noms:

Biz.Caching.ExpireDeadItems1
Biz.Caching.ExpireDeadItems2
Biz.Caching.ExpireDeadItems3

etc., pour chaque fil.

Answer 7

J'ai vu plusieurs conventions de nommage pour les threads dans .NET.

Certains préfèrent utiliser 't' au début du nom (par exemple tMain Thread) mais je ne pense pas qu'il ait une réelle valeur. Au lieu pourquoi ne pas simplement utiliser des noms descriptifs simples (variables de ligne) tels que HouseKeeping, Scheduler et ainsi de suite.