Copie de mutex en Go : préserver l'identité du verrou avec l'état qu'il protège

Ce que c'est

La documentation du paquet sync de Go indique qu'un Mutex ne doit pas être copié après sa première utilisation. Sa relation de synchronisation relie les opérations de déverrouillage et de verrouillage sur ce mutex. Une structure contenant un mutex a donc besoin d'une convention de propriété et de transmission qui préserve l'identité de l'objet de synchronisation pendant toute sa durée de vie active. Go sync Mutex

Pourquoi c'est important

Un agent peut ajouter un champ mutex et des appels de verrouillage sans revoir la façon dont l'objet englobant est transmis. Un récepteur par valeur ou une affectation peut compromettre la discipline de verrou unique prévue. La revue proposée suit l'objet à travers les constructeurs, les méthodes, les collections et les fonctions utilitaires, avant d'évaluer les sections critiques individuelles.

Comment l'appliquer

• Identifier l'état protégé par chaque mutex et l'objet exact détenant ce mutex. Écrire l'invariant selon lequel chaque accès doit partager la même identité de verrou.
• Examiner les récepteurs de méthode, les paramètres de fonction, les valeurs de retour et les affectations impliquant le type englobant. Vérifier les opérations sur conteneurs et les variables d'itération susceptibles d'introduire des copies par valeur.
• Choisir une convention de propriété explicite, généralement la transmission d'un pointeur vers le propriétaire stable, et aligner l'API sur cette convention. Ne pas exposer une opération de copie commode qui contredirait la règle de cycle de vie.
• Si les appelants ont besoin d'un instantané, construire un résultat séparé, purement constitué de données, tout en détenant le verrou approprié. Définir quelles valeurs sont copiées et si des données mutables imbriquées restent partagées.
• Proposer un scénario de test de non-régression utilisant les chemins réels, via les fonctions utilitaires et les conteneurs, qui copiaient auparavant le propriétaire. Vérifier le comportement de l'état partagé et exécuter les vérifications statiques et de concurrence pertinentes disponibles dans le projet.

Pièges

Un récepteur par pointeur seul n'empêche pas une copie explicite ailleurs. Préserver l'identité du mutex n'établit pas non plus un ordre de verrouillage correct, ni ne protège les accès qui contournent le verrouillage. Distinguer, dans la revue, les copies avant première utilisation des copies d'état actif prohibées ; éviter de s'appuyer sur un contrat de clonage non documenté. Il s'agit d'un audit de propriété proposé, et aucun résultat d'analyse statique ou de test de concurrence (race test) n'est revendiqué.