L'utilisation de std::deque ou std::priority_queue est-elle sûre pour les fils ?

Question

Duplicatas possibles :
La STL C++ std::set est-elle à l'abri des fils ?
Sécurité des threads pour les files d'attente STL

Je suppose que ce n'est pas le cas, je veux juste m'en assurer. c'est-à-dire 2 fils utilisant le même std::deque utilisant std::deque::push_back o push_front en même temps.

La même question se pose pour std::priority_queue et les fonctions std::priority_queue::push y std::priority_queue::pop ..

Ces conteneurs sont-ils sécurisés ? Ou devrais-je le programmer personnellement pour qu'il soit à l'abri des fils d'exécution ?

Merci beaucoup.

Answer 1

Extrait de l'article 12 de Effective STL de Scott Myer. Avoir des attentes réalistes quant à la sécurité des fils des conteneurs STL

Les lecteurs multiples sont sûrs. Plusieurs threads peuvent lire simultanément le contenu d'un seul conteneur, et cela fonctionnera correctement. Naturellement, aucun écrivain ne doit agir sur le conteneur pendant les lectures.

Les écrivains multiples vers des conteneurs différents sont sûrs. Plusieurs threads peuvent écrire simultanément dans différents conteneurs.

Lorsqu'il s'agit de threads sécurisés et de conteneurs STL, vous pouvez espérer une implémentation de la bibliothèque qui permette des lecteurs multiples sur un conteneur et plusieurs écrivains sur des conteneurs séparés. Vous ne pouvez pas espérer que la bibliothèque élimine le besoin de contrôle manuel de la concurrence, et vous ne pouvez pas compter sur un quelconque support de threads.

Answer 2

La STL ne fournit aucune garantie quant à la sécurité des fils. C'est notamment le cas lorsque l'on modifie le même conteneur à partir de plusieurs threads.

L'implémentation de la STL que vous utilisez peut fournir un certain niveau de sécurité thread, mais vous devez consulter la documentation de votre implémentation.

Answer 3

Lorsque vous dites qu'ils sont thread safe, vous voulez probablement dire que vous pouvez les utiliser dans plusieurs threads sans avoir à verrouiller quoi que ce soit.

En théorie, vous pourriez potentiellement avoir 2 threads, l'un poussant vers l'arrière et l'autre vers l'avant, et vous vous en sortiriez probablement, mais je me méfierais car l'implémenteur n'a pas la garantie de le rendre thread safe, car les itérateurs deviennent invalidés avec des insertions à chaque extrémité, si l'implémentation de push_back utilisait "end" et de push_front utilisait "begin", cela serait invalidé dans l'appel par l'autre thread, et pourrait vous exploser à la figure.

std::priority_queue n'est presque certainement pas utilisable dans deux threads ensemble, vraisemblablement pour les threads producteurs/consommateurs, avec un pushing et un popping et vous devrez verrouiller en premier.

J'ai découvert que lorsque j'ai écrit une file d'attente producteur/consommateur basée sur std::deque, j'ai permis au producteur de pousser plus d'un élément à la fois, et au consommateur de balayer toute la file d'attente à traiter. Cela signifie qu'il n'y a qu'un seul verrou par insertion en masse, ce qui réduit le nombre de verrouillages nécessaires.