.net: threading debug

Question

Quelles sont certaines des techniques disponibles pour déboguer les problèmes de multi-threading dans l'environnement .net.

Answer 1

Le débogage et le test multithread d'unité de code est notoirement difficile, et je ne crois pas qu'il existe des solutions éprouvées pour le débogage de plusieurs threads.

Cependant, vous pouvez le rendre plus facile d'écrire du code multithread en prenant quelques notes de langages de programmation fonctionnels:

Utiliser les structures de données immuables:

très facile à écrire du code multithread en F #, Haskell, Erlang, OCaml, etc. car les structures de données et les valeurs dans ces langages sont immuables, ce qui signifie que vous ne pouvez pas modifier une variable une fois qu'elle a été affectée. Essentiellement, cela signifie que chaque variable est déclarée constante, et il n'y a pas de méthodes comme List.Add ou Dictionary.Add qui mute la collection.

Immuabilité signifie que rien ne peut être muté après sa déclaration, donc vous n'avez jamais à vous soucier d'un état partagé de mutation de thread utilisé par un autre thread. Puisque c'est le cas, vous n'avez pas besoin d'utiliser des verrous ou des mutex dans votre code, et vous avez éliminé toute une classe d'erreurs de threading liées aux conditions de course et aux verrous morts.

Fiez passage de messages pour partager des données entre processus Lire ces blog:

• http://www.defmacro.org/ramblings/concurrency.html
• http://en.wikipedia.org/wiki/Erlang_(programming_language)#Concurrency_and_distribution_oriented_language

Erlang est un langage remarquable, en particulier parce que son modèle d'accès concurrentiel est évolutif jusqu'à 1000s et 1000s d'ordinateur. Plutôt que de donner l'accès aux threads à l'état partagé, il dépend du passage de message pour envoyer des informations d'un thread à un autre.

Rely sur les canaux à syncronize fils Voici une belle vidéo sur la langue Newsqueak: http://video.google.com/videoplay?docid=810232012617965344

Il décrit l'approche intéressante de Newsqueak à la concurrence. Il utilise des objets appelés "canaux" pour acheminer les données d'un fil à l'autre. Il est facile de trouver des implémentations C# de canaux. Rappelez-vous, vous pouvez en apprendre beaucoup sur la résolution de problèmes dans .NET en étudiant comment les mêmes problèmes sont résolus dans d'autres langages.

Answer 2

Une source de bogues multithread provient d'un échec de verrouillage des données utilisées à partir de plusieurs threads. Stress tester votre application est une technique pour révéler certains de ces problèmes. Plus il y a de threads qui sont confrontés à une fréquence plus élevée pour les données, plus les chances de repérer un problème sont grandes.

Repérer que vos données ont été corrompues par un accès non protégé peut être difficile. Votre application peut s'allonger pendant un certain temps avant de montrer des symptômes d'être malade. Les affirmations peuvent aider avec ceci. Ils vous donnent une meilleure chance de repérer la corruption très rapidement après qu'elle s'est produite.

L'autre type principal de bogue multithread est le blocage. Une technique que vous pouvez utiliser pour voir si votre application flirte avec des blocages est d'utiliser la vérification du niveau de verrouillage. Le contrôle du niveau de verrouillage n'attend pas pour repérer un blocage.Il vous avertit à l'exécution qu'il existe une possibilité de blocage.

La vérification du niveau de verrouillage fonctionne comme ceci: Supposons que vous ayez 3 verrous - A, B et C. Vous leur donnez respectivement les niveaux 1, 2 et 3. Si un thread revendique toujours un verrou de niveau inférieur avant un verrou de niveau supérieur, alors vous ne serez jamais dans une situation où un thread peut réclamer A puis B tandis que l'autre réclame B puis A. Pour implémenter le contrôle de niveau de verrouillage, donnez chacun de vos verrous objets un niveau. Utilisez le stockage local de threads pour qu'un thread sache quel niveau de verrouillage il a revendiqué en dernier. En fait, vous avez un objet pile dans le stockage local du thread, de sorte que lorsqu'un verrou est libéré, vous connaissez le niveau du verrou précédent. Certaines applications revendiquent des verrous qu'elles possèdent déjà. C'est sûr. Pour permettre cela dans le vérificateur de verrouillage des threads, vous devez analyser la pile de verrous pour voir si elle a déjà été revendiquée.

Tout ce contrôle de niveau de verrouillage impose une pénalité de performance. Il est donc probable qu'il soit approprié uniquement pour un débogage ou une construction spéciale.