Comment tester et comparer les implémentations de mutex


12

Comme le titre l'indique: Comment testez-vous et testez-vous correctement différentes implémentations de mutex en c ++?

Essentiellement, j'ai écrit ma propre classe de type std :: mutex pour un projet fonctionnant sur un noyau 2, armv7 dans le but de minimiser les frais généraux dans le cas non contesté. Maintenant, j'envisage d'utiliser ledit mutex dans plus d'endroits et également dans différentes architectures, mais avant de le faire, je voudrais m'assurer que

  • c'est en fait correct
  • il n'y a aucun cas pathologique dans lequel il fonctionne bien pire qu'un std :: mutex standard.

Évidemment, j'ai écrit quelques tests unitaires de base et des micro-benchmarks et tout semble fonctionner, mais en code multi-thread "semble fonctionner" ne me donne pas beaucoup de confort.

  • Existe-t-il donc des techniques d'analyse statique ou dynamique établies?
  • Quels sont les pièges courants lors de l'écriture de tests unitaires pour les classes mutex?
  • Quels sont les cas de bord typiques à surveiller (en termes de performances)?

J'utilise uniquement des types de bibliothèques standard pour l'implémentation, qui comprend des opérations de chargement et de stockage non cohérentes sur Atomics. Cependant, je suis principalement intéressé par les conseils agnostiques d'implémentation, car j'aimerais également utiliser le même faisceau de test pour d'autres implémentations.


2
Je sais que ce n'est pas obligatoire mais j'apprécierais que les downvoters commentent le problème de cette question. Je suis nouveau sur SE et je ne connais pas complètement les spécificités de ce site.
MikeMB

3
Pas l'électeur, mais je dirai que ce site est particulièrement mauvais pour les votes anonymes sur des questions parfaitement bonnes. Il me semble que beaucoup de gens votent contre ce que j'appellerais des raisons "religieuses". Cela dit, une possibilité est que vous demandiez des recommandations sur les outils, ce qui, je crois, est mal vu ici. Mais ce n'est qu'une supposition. Et beaucoup de gens ont discuté de ces outils dans d'autres questions, alors faites-en ce que vous voulez.
user1118321

4
En fait, consultez ce méta-article intitulé "Downvoting parce que nous ne sommes pas d'accord avec l'approche ou la logique du demandeur".
user1118321

@ user1118321: ce meta post ne correspond pas à cette question car à mon humble avis il n'y a pas d'hypothèse erronée dans cette question. Cependant, deux des trois votes fermés que je vois actuellement utilisent la raison de fermeture prédéfinie "demande de ressources tierces". MikeMB, vous pouvez essayer de modifier votre question et d'en supprimer ces parties, mais dans la forme actuelle, je suppose que la communauté pourrait également la fermer pour être trop large. Si vous réduisez le champ de la question et demandez spécifiquement ce que vous voulez tester et ce que vous avez essayé jusqu'à présent, vous pouvez augmenter les chances de survie de votre question.
Doc Brown

Un problème avec cette question est que «les questions nous demandant de trouver ou de recommander des outils, des bibliothèques, des langages de programmation, des ressources (y compris des livres, des blogs, des didacticiels et des exemples) ou des projets à entreprendre sont hors sujet ici car elles attirent des réponses avisées qui n'aura pas de valeur durable pour les autres. "
David Hammen

Réponses:


1

La question est complexe:

Certaines sources de complexité comprennent:

  • Combien de changements de contexte ont lieu: cela est très important selon la plate-forme sur laquelle ces tests s'exécutent. Certaines plates-formes gèrent mieux que d'autres
  • Les fonctions que les mutex sont testées sont-elles en ligne ou non? c'est-à-dire que le mutex fonctionne bien uniquement dans un code bien optimisé ou optimisable.
  • Ces mutex sont-ils conçus pour la localité de cache. Les erreurs de cache réduiront considérablement les performances ou entraîneront plus de changements de contexte. avant et après l'entrée du mutex.
  • Le mutex lui-même entraînera-t-il une perte de la mémoire cache. c'est-à-dire que les données d'état mutex sont allouées dynamiquement.
  • Ces mutex fonctionneront-ils bien là où les changements de contexte sont contenus dans le mutex. ie io, malloc etc.
  • Le mutex fonctionnera-t-il bien si le temps du noyau est contenu dans l'allocation et la désaffectation dynamiques de la mémoire mutex.ie.
  • Les performances sont-elles valables lors de l'exécution au sein de VM
  • La destruction ou la construction du mutex est-elle coûteuse, c'est-à-dire que les données d'état sont situées dans la mémoire dynamique

1
Je ne sais pas si je suis d'accord avec la partie construction / destruction. Si un programme crée et détruit vos mutex tout le temps, il y a (à mon humble avis) quelque chose de mal avec la conception du design. Mais sinon merci pour les pointeurs.
MikeMB

-1

Votre idée est très intéressante: un référentiel de conformité par rapport auquel une implémentation de mutex pourrait être testée.

Malheureusement, à ma connaissance, il n'y a pas de référence de conformité largement connue pour les implémentations de mutex. Donc, je suppose que vous avez entre les mains le problème très intéressant de créer une proposition pour un tel référentiel de conformité.

Et, puisque vous avez participé à la création d'une implémentation de référence, vous êtes le gars.

Si vous me permettez une suggestion, vous pourriez peut-être commencer cette recherche avec le standard POSIX pour les threads d'un côté, et une étude de la littérature théorique du traitement simultané, comme CSP, ou Communicating Sequential Processes. Ce type d'articles traite généralement des problèmes concurrents classiques, comme les philosophes de la restauration.

Leur mise en œuvre pourrait être une partie intéressante de votre référence en matière de conformité, je suppose.


3
Je ne vous ai pas déçu, mais cela ne semble répondre à aucune de mes questions.
MikeMB

Merci de ne pas avoir voté. Et désolé de ne pas avoir répondu à vos questions. Cela vous dérangerait-il que je vous demande si vous envisagez de créer une référence de conformité pour les mutex?
Hilton Fernandes

Peu probable. Et même si, la seule norme qui m'importe est la norme c ++ (bien que cela puisse être le même que le posix en ce qui concerne les mutex)
MikeMB

Pour qualifier ma déclaration précédente: si je devais proposer une bonne suite de tests pour mon propre mutex, je le ferais probablement en open source, mais je doute fort qu'il ait la qualité ou qu'il soit suffisamment complet pour devenir un véritable repère de «conformité» - qui pourrait de toute façon être mieux géré par l'analyse statique.
MikeMB

Je suis d'accord avec vous qu'il n'y a pas de bonne suite de tests pour les primitives mutex. Je suppose que cela devrait provenir de trois sources distinctes: la théorie du traitement simultané, la spécification d'un mutex POSIX et les algorithmes concurrents exprimés à l'aide de mutex. Êtes-vous d'accord avec cela ?
Hilton Fernandes
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.