mutex ou ne pas mutex, doit-on protéger les std::queue

Bonjur,
je suis en train de développer une application pour envoyer des requêtes à intervalles réguliers. Pour cela , j'utilise un thread, qui ,a intervalles données ,va interroger une file d'attente (de type <queue>) si la liste est vide on non dans le cas elle elle contiendrait un élément l'envoyer puis le supprimer de la file.
Or je ne sais pas si je ne devrai pas mettre un mutex entre l'envoie et la scrutation. Normalement il n'y a que le thread principal qui ajoute des éléments, et qu'un seul thread qui vérifie la présence ou non d'élément et qui dépile <queue> est de type FIFO.

Donc ma question serai de savoir si un mutex s'avérait nécessaire pour "protéger" d'interblocage , sachant que pour etre efficace, l'insertion devrai aussi se faire via un autre thread puisque le thread principal s'en fiche qu'il y en ai un ...
Merci d'avance.

Salut,

Oui il faut, les conteneurs STL ne sont pas thread-safe.

MAT.

Le thread 1 commence à modifier le conteneur
Le thread 2 lit la valeur
Le thread 1 finit de modifier le conteneur.

Le thread 2 peut donc lire des données alors que le conteneur est dans un état invalide, voire pire, corrompre celui-ci ou causer une erreur.

il y a des moyens de faire sans objet de synchronisation, avec des instructions "atomiques" (ou interlocked)
et il se peut que la meilleure synchronisation soit le semaphore das ton cas (le thread principal ajoute dans la liste et "release" le semaphore ce qui debloque le second thread qui etait en attente de lecture)