Heisenbug et Chess

Vous connaissez le principe d’incertitude d’Heisenberg (https://fr.wikipedia.org/wiki/Heisenberg ), « Heisenbug » est une manière de qualifier des bugs incertains dans le sens ou ils sont très difficiles à prédire et à identifier, ils ne surviennent que de temps en temps dans des conditions quasiment impossible à reproduire, bref la bête noire des développeurs et des centres de support. (le terme est également défini dans Wikipedia https://fr.wikipedia.org/wiki/Heisenbug , mais la rubrique est incomplète sur le plan des codes parallèle… ce post tente de combler cette lacune J )

Pour info les termes Bohr bug , Heisenbug et Schrödinbug existent également et correspondent à d’autre cas rares et sont eux aussi les bêtes noires des dev et support (ils sortent du cadre que je me suis fixé pour ce post, mais j’y reviendrait peut être dessus un autre jour…)

 

A la PDC Microsoft Research anime quelques stands ; et oui c’est aussi cela la PDC, la possibilité de rencontrer quelques chercheurs de Microsoft Research, prêt a vous allouer du temps pour vous expliquer 5 – 6 de leur projets et de vous faire des démos : Respect !

 

Parmi ces projets un qui nous anime depuis quelques temps EricV et moi même : Chess. (research.microsoft.com/chess)

Chess est un outil d’analyse des codes parallèles, il permet de mettre a jour « toutes » les combinaison possibles d’acquisition de verrous dans vos code et vous permet d’identifier des cas de figures qui ne produiront peut être jamais, mais dont la probabilité d’apparition est différente de zéro. Et comme vous le savez via la loi de Murphy (appelée par certain loi de l’emer… maximum) c’est au moment le plus critique que ces bombes à retardement feront le plus de dégâts.

Prenons le cas simple d’un race condition, dans votre code 2 thread vont acquérir une ressource partagée, le code compile et tourne parfaitement car T1 arrivent dans 99.99% des cas en premier sur un verrou, Chess identifie que T1 et T2 vont se partager un verrou, alors Chess génère la matrice de tout les cas possible, et en instrumentant votre code va garantir que dans votre test tantôt T1 arrive le premier, mais bloquera T1 pour permettre la situation ou T2 arrive le premier sur la ressource. La combinatoire de cet exemple est simplissime, mais imaginez ce que ca peut devenir si vous avez une dizaine de thread et de verrous dans votre code, devenir exhaustif dans vos tests relève du casse tête et nécessitent une instrumentation manuelle du code (opération délicate et couteuse en temps) Grace à Chess pour êtes garanti de produire tous les cas possibles que ce soit dans du code natif ou managé ! (Champion MSR !!!)

Les démos qui nous été faite ce PM, (a ericV et moi-même)par S. Qadeer (le gars est impressionant de vivacité et signe des publications sur Chess... la aussi Respect !), s’appuyaient sur du code managé (PFX et PLinq), et étaient totalement intégrées à Visual Studio 2008, dans un Test unitaire (Whaouh, que de chemin parcours en quelques mois par cette équipe de chercheurs, alors que les versions du mois de mai dernier n’étaient dispo qu’en mode commande et que sur du code natif…. )

Et oui c’est aussi cela la PDC… du pur bonheur du matin au soir… à condition d’aimer le code J

 

Eric.PDC.Addict J