Contemplation de std::lock_guard vs. std::scoped_lock

C 17 a marqué l'introduction d'une nouvelle classe de verrouillage, std::scoped_lock , qui partage des similitudes avec le vénérable std::lock_guard. Cet article approfondit les distinctions entre ces deux mécanismes de verrouillage, vous guidant dans le choix de l'outil optimal pour vos besoins spécifiques.

Quand utiliser std::lock_guard

Pour Dans les scénarios où vous avez besoin du verrouillage d'un seul mutex pour l'intégralité d'une portée, std::lock_guard propose une API plus sûre que std::scoped_lock. Prenons l'exemple suivant :

{
    std::scoped_lock lock;  // protect this block
    ...
}

Cet extrait entraîne par inadvertance une erreur d'exécution, car il adopte un « comportement invisible ». Il semble se compiler sans problème mais n'effectue finalement aucun verrouillage. La fonctionnalité prévue nécessitait probablement :

{
    std::scoped_lock lock{mut};  // protect this block
    ...
}

La clarification du mutex cible pour le verrouillage résout ce problème. À l'inverse, l'utilisation de std::lock_guard empêcherait la compilation du premier exemple, ce qui en ferait une erreur évidente au moment de la compilation.

Quand utiliser std::scoped_lock

Quand confronté à des situations où plusieurs mutex nécessitent un verrouillage, std::scoped_lock brille. Par exemple:

{
    std::scoped_lock(lock1, lock2);  // protect this block
    ...
}

Cet extrait verrouille succinctement deux mutex pour la durée du bloc.

Conclusion

Les deux std::lock_guard et std::scoped_lock répondent à des scénarios distincts :

• std::lock_guard pour verrouiller un seul mutex dans une portée.
• std::scoped_lock pour verrouiller plusieurs mutex ou pour déverrouiller dans la portée incluse.

Bien que std::scoped_lock fournisse des fonctionnalités plus complètes, std::lock_guard offre une sécurité API améliorée dans des cas spécifiques. Tenez compte attentivement des exigences de votre code lors de la sélection de l'approche la plus appropriée.