J'ai du mal à trouver des informations à jour à ce sujet.
Les versions C++ 11 des conteneurs STL ont-elles un certain niveau de sécurité des threads garanti?
Je m'attends à ce qu'ils ne le fassent pas, pour des raisons de performances. Mais là encore, c'est pourquoi nous avons les deux std::vector::operator[]
et std::vector::at
.
Étant donné que les réponses existantes ne le couvrent pas (seul un commentaire le fait), je mentionnerai simplement 23.2.2 [container.requirements.dataraces] du courant spécification standard C++ qui dit:
des implémentations sont nécessaires pour éviter les courses de données lorsque le contenu de l'objet contenu dans différents éléments de la même séquence, à l'exception de
vector<bool>
, est modifié simultanément.
c'est-à-dire qu'il est sûr d'accéder à des éléments distincts du même conteneur, par exemple, vous pouvez avoir un std::vector<std::future<int>>
global de dix éléments et avoir dix threads qui écrivent chacun sur un élément différent du vecteur.
En dehors de cela, les mêmes règles s'appliquent aux conteneurs que pour le reste de la bibliothèque standard (voir 17.6.5.9 [res.on.data.races]), comme réponse de Mr.C64 dit, et en plus [container.requirements.dataraces] répertorie certaines fonctions membres non const de conteneurs qui peuvent être appelées en toute sécurité car elles ne renvoient que des références non const à des éléments, elles ne modifient en fait rien (en général, toute fonction membre non const doit être considéré comme une modification.)
Je pense que les conteneurs STL offrent la garantie de sécurité des fils de base suivante:
lectures simultanées de l'objet identique sont OK
lecture/écriture simultanées sur différent les objets sont OK
Mais vous devez utiliser une forme de synchronisation personnalisée (par exemple, une section critique) si vous voulez faire quelque chose de différent, comme par exemple écrit simultanément sur le même objet.