Comment utiliser RWMutex dans Golang?

Lorsque plusieurs threads* doit muter la même valeur, un mécanisme de verrouillage est nécessaire pour se synchronise accès. Sans elle, deux ou plusieurs threads* peut être écrit à la même valeur dans le même temps, résultant en une corruption de la mémoire qui résulte généralement d'un crash.

La atomique paquet fournit un moyen rapide et facile pour synchroniser l'accès à des valeurs primitives. Pour un compteur, il est le plus rapide de la méthode de synchronisation. Il a des méthodes bien définies de cas d'utilisation, tels que l'incrémentation, décrémentation, des échanges, etc.

La synchronisation paquet fournit un moyen de synchroniser l'accès plus compliqué de valeurs, telles que des cartes, des tranches, des tableaux, ou des groupes de valeurs. Vous utilisez ce pour les cas d'utilisation qui ne sont pas définis dans atomique.

Dans les deux cas, le verrouillage est nécessaire uniquement lors de l'écriture. Plusieurs threads* sans danger de lire la même valeur, sans un mécanisme de verrouillage.

Permet de jeter un coup d'oeil au code que vous avez fournis.

type Stat struct {
    counters     map[string]*int64
    countersLock sync.RWMutex
    averages     map[string]*int64
    averagesLock sync.RWMutex
}

func (s *Stat) Count(name string) {
    s.countersLock.RLock()
    counter := s.counters[name]
    s.countersLock.RUnlock()
    if counter != nil {
        atomic.AddInt64(counter, int64(1))
        return
    }
}

Ce qui manque ici est de savoir comment la carte est eux-mêmes sont initialisés. Et jusqu'à présent, les cartes ne sont pas muté. Si le compteur noms sont déterminés à l'avance et ne peuvent pas être ajoutées plus tard, vous n'avez pas besoin de la RWMutex. Ce code pourrait ressembler à quelque chose comme ceci:

type Stat struct {
    counters map[string]*int64
}

func InitStat(names... string) Stat {
    counters := make(map[string]*int64)
    for _, name := range names {
        counter := int64(0)
        counters[name] = &counter
    }
    return Stat{counters}
}

func (s *Stat) Count(name string) int64 {
    counter := s.counters[name]
    if counter == nil {
        return -1 //(int64, error) instead?
    }
    return atomic.AddInt64(counter, 1)
}

(Note: j'ai supprimé des moyennes car il n'était pas utilisé dans l'exemple original.)

Maintenant, disons que vous ne voulez pas que vos marqueurs pour être prédéterminé. Dans ce cas, vous auriez besoin d'un mutex pour synchroniser l'accès.

Permet d'essayer avec juste un Mutex. C'est simple, car un seul thread* peut contenir Verrouillage à la fois. Si un deuxième thread* essaie de Verrouillage avant les premières versions d'eux avec Déverrouiller, il attend (ou blocs)** jusqu'alors.

type Stat struct {
    counters map[string]*int64
    mutex    sync.Mutex
}

func InitStat() Stat {
    return Stat{counters: make(map[string]*int64)}
}

func (s *Stat) Count(name string) int64 {
    s.mutex.Lock()
    counter := s.counters[name]
    if counter == nil {
        value := int64(0)
        counter = &value
        s.counters[name] = counter
    }
    s.mutex.Unlock()
    return atomic.AddInt64(counter, 1)
}

Le code ci-dessus fonctionne très bien. Mais il y a deux problèmes.

1. Si il y a une panique entre Lock() et Unlock() le mutex sera fermé pour toujours, même si vous étiez à récupérer à partir de la panique. Ce code ne sera probablement pas à la panique, mais en général il est préférable de supposer qu'il le pourrait.
2. Un verrou exclusif est pris lors de l'extraction du compteur. Un seul thread* peut lire le compteur à la fois.

Le problème n ° 1 est facile à résoudre. Utilisation reporter:

func (s *Stat) Count(name string) int64 {
    s.mutex.Lock()
    defer s.mutex.Unlock()
    counter := s.counters[name]
    if counter == nil {
        value := int64(0)
        counter = &value
        s.counters[name] = counter
    }
    return atomic.AddInt64(counter, 1)
}

Cela garantit que Unlock() est toujours appelé. Et si pour une raison quelconque vous avez plus d'un retour, vous avez seulement besoin de spécifier de Déverrouillage() une fois à la tête de la fonction.

Problème n ° 2 peut être résolu avec RWMutex. Comment ça fonctionne exactement, et pourquoi est-il utile?

RWMutex est une extension de Mutex et ajoute deux méthodes: RLock et RUnlock. Il y a quelques points qui sont importants à noter à propos de RWMutex:

• RLock est partagée verrou en lecture. Lorsqu'un verrou est pris avec elle, les autres threads* peuvent aussi faire leur propre cadenas avec RLock. Cela signifie que plusieurs threads* peut lire en même temps. Il est semi-exclusif.

• Si le mutex est de lire verrouillé, un appel à Verrouillage est bloqué**. Si un ou plusieurs lecteurs de placer un verrou, vous ne pouvez pas écrire.

• Si le mutex est d'écrire verrouillé (avec Verrouillage), RLock bloquera**.

Une bonne façon de penser est RWMutex est un Mutex avec un lecteur de compteur. RLock incrémente le compteur tout en RUnlock décrémente. Un appel à Verrouillage bloquera tant que le compteur est > 0.

Vous pensez peut-être: Si ma demande est de lire lourds, que cela signifierait un écrivain peut être bloqué indéfiniment? Pas de. Il y a une propriété utile de RWMutex:

• Si le lecteur de compteur est > 0 et Verrouillage est appelé, les futurs appels à RLock permet également de bloquer jusqu'à ce que l'existant lecteurs ont publié leurs verrous, l'écrivain a obtenu son de verrouillage et les versions ultérieures il.

Penser comme la lumière au-dessus d'un registre à l'épicerie qui dit que la caisse est ouverte ou pas. Les gens à la ligne arrive à rester là et ils seront aidés, mais de nouvelles personnes ne peuvent pas obtenir en ligne. Dès que le dernier client est aidé la caisse va sur pause, et que le registre soit reste fermé jusqu'à ce qu'ils reviennent ou qu'ils sont remplacés par une autre caisse.

Permet de modifier l'exemple précédent avec une RWMutex:

type Stat struct {
    counters map[string]*int64
    mutex    sync.RWMutex
}

func InitStat() Stat {
    return Stat{counters: make(map[string]*int64)}
}

func (s *Stat) Count(name string) int64 {
    var counter *int64
    if counter = getCounter(name); counter == nil {
        counter = initCounter(name);
    }
    return atomic.AddInt64(counter, 1)
}

func (s *Stat) getCounter(name string) *int64 {
    s.mutex.RLock()
    defer s.mutex.RUnlock()
    return s.counters[name]
}

func (s *Stat) initCounter(name string) *int64 {
    s.mutex.Lock()
    defer s.mutex.Unlock()
    counter := s.counters[name]
    if counter == nil {
        value := int64(0)
        counter = &value
        s.counters[name] = counter    
    }
    return counter
}

Avec le code ci-dessus j'ai séparé la logique dans getCounter et initCounter fonctions:

• Avoir un code simple à comprendre. Il serait difficile de RLock() et Lock() dans la même fonction.
• Libérer les verrous le plus tôt possible lors de l'utilisation de reporter.

Le code ci-dessus, à la différence de la Mutex exemple, vous permet d'incrémenter les compteurs différents simultanément.

Une autre chose que je voulais souligner est que, avec tous les exemples ci-dessus, la carte map[string]*int64 contient des pointeurs vers les compteurs à zéro, de ne pas les compteurs eux-mêmes. Si vous devez stocker les compteurs de la carte map[string]int64 vous devez utiliser Mutex sans atomique. Ce code devrait ressembler à quelque chose comme ceci:

type Stat struct {
    counters map[string]int64
    mutex    sync.Mutex
}

func InitStat() Stat {
    return Stat{counters: make(map[string]int64)}
}

func (s *Stat) Count(name string) int64 {
    s.mutex.Lock()
    defer s.mutex.Unlock()
    s.counters[name]++
    return s.counters[name]
}

Vous pouvez faire pour réduire la collecte des ordures ménagères - mais ce ne importe si vous avait des milliers de compteurs et les compteurs eux-mêmes ne prennent pas beaucoup d'espace (par rapport à quelque chose comme un tampon d'octets).

* Quand je dis thread je veux dire allez-routine. Un thread dans d'autres langues est un mécanisme pour l'exécution d'un ou de plusieurs programmes simultanément. Un thread est coûteux de créer et de démontage. Un aller-routine est construite au-dessus des fils, mais le ré-utilise. Lorsqu'un aller-routine dort sous-jacents fil peut être utilisé par un autre aller-routine. Lorsqu'un aller-routine se réveille, il pourrait être sur un thread différent. Aller gère tout cela derrière les coulisses. - Mais pour toutes fins utiles, vous le feriez à un aller-routine comme un fil quand il s'agit de l'accès à la mémoire. Cependant, vous n'avez pas à être prudente lors de l'utilisation de go-routines que vous ne threads.

** Lorsqu'un aller-routine est bloqué par Lock, RLock, un canal, ou Le sommeil, le thread peut être ré-utilisé. Pas de cpu est utilisé par qui vont-routine - il pense que l'attente en ligne. Comme les autres langues une boucle infinie comme for {} bloquerait tout en gardant le cpu et la routine occupé pense que comme courir dans un cercle - vous obtiendrez des étourdissements, de vomir, et les gens autour de vous ne sera pas très heureux.