Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace.
Juste pour compléter, l'outil race detector est basé sur de la détection des accès concurrents non protégés qui se produisent lors des tests unitaires lancés avec le mode race ou sur une des instances en production qui a été compilée avec le mode race. Les erreurs sont sorties sur l'erreur standard, elles donnent les goroutines incriminées en écriture (voire en lecture) et la zone mémoire (variable, tableau...).
Il n'analyse pas le code source pour trouver les accès concurrents non protégés (pas d'analyse statistique). Il ne permet pas de garantir que le code est sûr s'il ne détecte rien par contre s'il détecte une erreur c'est vraiment un accès concurrent non protégé qu'il faudra corriger. Il n'est donc pas parfait mais il a le mérite d'exister.
Pour moi, le couple benchmark ou test unitaire avec plusieurs appels en parallèle (par exemple pour une API WS plusieurs requêtes jouées lors des tests unitaires) et le mode race activé fonctionne très bien. Il me donne une bonne garantie que le code est sûr d'un point de vue des accès concurrences non protégés et il est exécuté dans la CI sur chaque push.
[^] # Re: Rust et SIMD
Posté par woffer 🐧 (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.
Juste pour compléter, l'outil race detector est basé sur de la détection des accès concurrents non protégés qui se produisent lors des tests unitaires lancés avec le mode race ou sur une des instances en production qui a été compilée avec le mode race. Les erreurs sont sorties sur l'erreur standard, elles donnent les goroutines incriminées en écriture (voire en lecture) et la zone mémoire (variable, tableau...).
Il n'analyse pas le code source pour trouver les accès concurrents non protégés (pas d'analyse statistique). Il ne permet pas de garantir que le code est sûr s'il ne détecte rien par contre s'il détecte une erreur c'est vraiment un accès concurrent non protégé qu'il faudra corriger. Il n'est donc pas parfait mais il a le mérite d'exister.
Pour moi, le couple benchmark ou test unitaire avec plusieurs appels en parallèle (par exemple pour une API WS plusieurs requêtes jouées lors des tests unitaires) et le mode race activé fonctionne très bien. Il me donne une bonne garantie que le code est sûr d'un point de vue des accès concurrences non protégés et il est exécuté dans la CI sur chaque push.