IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SL & STL C++ Discussion :

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


Sujet :

SL & STL C++

  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Mars 2002
    Messages
    312
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2002
    Messages : 312
    Par défaut 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.

  2. #2
    Membre Expert

    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 294
    Détails du profil
    Informations personnelles :
    Localisation : Royaume-Uni

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 294
    Par défaut
    Salut,

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

    MAT.

  3. #3
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    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.

  4. #4
    screetch
    Invité(e)
    Par défaut
    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)

Discussions similaires

  1. [Mutex] Comment faire des mutex non réentrants ?
    Par chronos dans le forum Windows
    Réponses: 11
    Dernier message: 08/02/2008, 11h51
  2. [D7][Mutex] ne fonctionne pas comme attendu !
    Par jbat dans le forum Delphi
    Réponses: 8
    Dernier message: 25/06/2007, 12h35
  3. [TP] Pas le temps de voir les résultats à l'écran
    Par bonomsoleil dans le forum Turbo Pascal
    Réponses: 5
    Dernier message: 08/02/2006, 22h49
  4. Je ne trouve pas la requete pour modifier les entrées...
    Par guttts dans le forum Langage SQL
    Réponses: 7
    Dernier message: 24/08/2005, 19h17
  5. protéger les images des internautes ?
    Par WBO dans le forum Balisage (X)HTML et validation W3C
    Réponses: 7
    Dernier message: 17/05/2005, 17h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo