Que faut-il garder à l'esprit lors de l'utilisation…

Lorsqu'on travaille avec des mutex (sync.Mutex) en Go, il est important de se rappeler ce qui suit :

Prise et libération : Il faut obligatoirement acquérir (Lock()) le mutex avant d'accéder aux données partagées et le libérer (Unlock()) après avoir terminé. Utiliser defer mu.Unlock() immédiatement après mu.Lock() est une bonne pratique pour éviter d'oublier de le libérer.
Exclusivité : Le mutex offre un accès exclusif à une ressource à un seul goroutine à la fois.
État "bloqué/débloqué" : Appeler Lock() sur un mutex déjà bloqué entraînera le blocage du goroutine jusqu'à ce qu'il soit libéré par un autre. Appeler Unlock() sur un mutex non bloqué provoquera un panic à l'exécution.
Ne pas copier les mutex : La structure sync.Mutex n'est pas conçue pour être copiée après sa première utilisation. Passer un mutex par valeur ou copier la structure qui le contient peut entraîner une synchronisation incorrecte et des panics.
Deadlocks (verrouillages mutuels) : Se produisent lorsque deux ou plusieurs goroutines attendent que l'autre libère des ressources. Exemple typique : la goroutine A bloque R1 et attend R2, tandis que la goroutine B bloque R2 et attend R1.
Livelocks (verrouillages vivants) : Situation où les goroutines changent constamment d'état en réponse aux actions des autres, sans effectuer de travail utile ni avancer. C'est moins fréquent que le deadlock.
Famine (starvation) : Situation où une ou plusieurs goroutines ne peuvent pas accéder à une ressource partagée parce qu'elle est constamment verrouillée par d'autres. La famine n'est pas garantie avec les mutex Go.
Utilisation de sync.RWMutex pour lecture/écriture : Si la majorité des opérations sont des lectures et que les écritures sont rares, sync.RWMutex peut être plus efficace. Il permet à plusieurs goroutines de lire simultanément, mais bloque lors d'une écriture.
Verrouillages courts : Essayez de garder les verrouillages aussi courts que possible. Plus un mutex est verrouillé longtemps, plus d'autres goroutines devront attendre, ce qui réduit le parallélisme.
Test de conditions de course : Utiliser le drapeau -race lors de la compilation et de l'exécution des tests (go test -race) aide à détecter les conditions de course, souvent causées par une mauvaise utilisation des mutex.

Exemple d'utilisation de defer :

import (
	"sync"
)

type SafeCounter struct {
	mu sync.Mutex
	v  map[string]int
}

// Inc incrémente en toute sécurité le compteur pour une clé donnée.
func (c *SafeCounter) Inc(key string) {
	c.mu.Lock()
	// Libération différée à la sortie de la fonction.
	defer c.mu.Unlock()
	c.v[key]++
}

// Value retourne la valeur actuelle du compteur pour une clé donnée.
func (c *SafeCounter) Value(key string) int {
	c.mu.Lock()
	// Libération après avoir obtenu la valeur.
	defer c.mu.Unlock()
	return c.v[key]
}

Que faut-il garder à l'esprit lors de l'utilisation de mutex en Go?