Pourquoi « sync.Mutex » de Go ne prend-il pas en charge le verrouillage récursif ?

Verrouillage récursif

Go's sync.Mutex fournit un mécanisme de synchronisation robuste pour la programmation simultanée. Cependant, il ne prend pas en charge le verrouillage récursif, ce qui peut poser un défi dans certains scénarios.

Pourquoi ne pas implémenter des verrous récursifs ?

Bien qu'il puisse sembler logique de implémentez des verrous récursifs dans Go, il est important de prendre en compte les principes sous-jacents de la synchronisation. Comme le dit avec éloquence Russ Cox de l'équipe de développement de Go, les mutex récursifs "ne protègent pas les invariants".

Les primitives mutex sont conçues pour renforcer la sécurité des threads et garantir la cohérence des données. Lorsqu'un mutex est détenu, il garantit que les structures de données protégées sont dans un état valide. Les verrous récursifs, cependant, rompent cette garantie en permettant aux threads d'acquérir le même mutex plusieurs fois au sein d'un même chemin d'exécution. Cela peut conduire à un comportement incorrect ou indéfini, ce qui rend intrinsèquement difficile le maintien de l'intégrité des données.

Solutions alternatives

Au lieu de recourir à des verrous récursifs, il est recommandé de repenser le code. pour éviter leur besoin en premier lieu. Une approche plus robuste et évolutive consiste à séparer le code protégé en petites tâches atomiques qui peuvent être exécutées en dehors de la portée de tout mutex. Cela garantit que les données protégées restent cohérentes tout au long de l'exécution entière du code.

Exemple

Considérez l'exemple fourni dans la réponse de Russ Cox :

func F() {
    mu.Lock()
    ... do some stuff ...
    G()
    ... do some more stuff ...
    mu.Unlock()
}

func G() {
    mu.Lock()
    ... do some stuff ...
    mu.Unlock()
}

Ce code démontre les pièges potentiels liés à l'utilisation de verrous récursifs. Si F brise les invariants qu'il est chargé de protéger avant d'appeler G, G continuera à opérer sur les données incohérentes, conduisant à des résultats erronés.

Pour résoudre ce problème, une approche plus appropriée serait de définir un assistant distinct fonction g qui ne nécessite pas la protection mutex :

// To be called with mu already held.
func g() {
    ... do some stuff ...
}

func G() {
    mu.Lock()
    g()
    mu.Unlock()
}

Cette approche garantit que G fonctionne toujours sur les données protégées lorsqu'elles sont dans un état cohérent, évitant ainsi les risques associé aux verrous récursifs.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!