Qu'est-ce qui pourrait provoquer un blocage ou provoquer l'échec de ce test de simultanéité?

Question

J'ai tripoté avec CHESS, ce qui me semble être un outil incroyablement utile. Cependant, ironiquement, j'ai l'impression d'avoir affaire à un Heisenbug dans l'une de mes méthodes d'essai. Les résultats rapportés par CHESS quand je lance ce test sont imprévisibles:

• Parfois, le test passera
• Parfois, le test échouera, sans autre description (simplement: « Le test a échoué »)
• Parfois, la test échouera avec des instructions pour dupliquer *
• Parfois, le test indiquera « CHESS détecté impasse »

au départ, je pensais que cette incohérence doit être dû au fait que le test implique l'utilisation d'objets Random. Il a dû être que différentes valeurs de semences produisaient des résultats différents, non? J'ai donc mis à jour le test pour qu'il s'exécute simplement pour un ensemble prédéfini de valeurs de départ (de 0 à 10). Les objets thread-local Random sont ensemencés par une valeur (pseudo-) aléatoire générée par un Random partagé dans un verrou. Le code semble essentiellement exactement comme ceci:

(Mise à jour: Je cours ceci sur .NET 3.5, comme CHESS ne supporte que VS 2008. Je me demande si le problème pourrait avoir quelque chose à faire avec this?)

Si je comprends bien, le code ci-dessus devrait en fait être assez déterministe. Puisque sharedRandom est initialisé avec un germe connu (entre 0 et 10), les valeurs produites par l'objet localRandom appartenant à chaque thread exécutant le code à l'intérieur de l'appel Parallel.For doivent être cohérentes d'un essai à l'autre (quel thread obtient quelle graine de sharedRandom peut différer entre les exécutions, mais parmi les 5 itérations dans Parallel.For, les mêmes 5 graines devraient être utilisées pour localRandom).

Voilà comment le I le comprend. Mais à partir des résultats de l'ÉCHEC, j'ai tendance à croire qu'il me manque quelque chose.

1. Y at-il un blocage dans le code ci-dessus que je suis trop bête pour voir?
2. Est-ce que je ne devrais pas utiliser la classe Random dans les tests liés à la concurrence?
3. Pour ceux qui ont de l'expérience avec CHESS: est-ce un outil fiable? Est-ce que cela donne parfois des faux positifs? C'est en fait un gros problème, comme s'il s'avérait que ce scénario est commun (résultats de test incohérents), alors il serait peut-être bon de ne plus utiliser CHESS pour l'instant.

_{* ... que je n'ai pas été capable de comprendre comment utiliser - mais c'est un problème distinct.}

Answer 1

Pas de réponses, je vais tenter le coup. Ce n'est pas évident pour moi comment l'extrait posté pourrait échouer, je soupçonne que le vrai problème est dans le commentaire.Je n'ai pas d'expérience pratique avec CHESS, mais je l'ai suffisamment étudié pour savoir que vous ne pouvez pas compter sur lui pour vous donner des résultats de tests reproductibles. Son approche pour découvrir les problèmes de threading est très statistique, injectant des retards aléatoires dans les threads. Conçu pour recréer le genre de problèmes de filetage qui sont si fortement influencés par le timing, en particulier les conditions de course.

Une condition de concurrence peut passer inaperçue pendant très longtemps si le temps d'exécution du code est prévisible. Et quand il frappe, incroyablement difficile à diagnostiquer. Un bon exemple de cela est un grand projet gouvernemental dont j'ai entendu parler et qui a été livré avec l'enregistrement. Parce que avec elle éteint il ne fonctionnerait plus et il n'y avait pas de bon moyen de diagnostiquer le problème sans les informations de journalisation.

Menace CHESS en tant qu'outil de diagnostic. Si elle soulève un drapeau, vous pouvez être sûr que vous avez un vrai, mais toujours difficile à résoudre, problème de threading.

Answer 2

Je ne vois certainement pas une impasse ici. Il est probable que Random ait un verrouillage interne, mais ça devrait aller.

Vous pouvez essayer Jinx (www.corensic.com). Plutôt que de produire un rapport, Jinx modifie simplement les performances effectives des différents processeurs. Donc, il ne peut pas vraiment produire de faux positifs.

Si le minuscule échantillon se bloque sous Jinx, il est définitivement capable de se bloquer dans une utilisation normale. En supposant que le blocage se produise, vous devriez être en mesure de percer le blocage avec Visual Studio et de voir où se trouvent les threads.

Avis de non-responsabilité. Je travaille pour corensic. Et je ne pense pas que le petit extrait que vous avez posté est vraiment une impasse. Mais je suis curieux, alors laissez-nous savoir ce que vous trouvez.