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

Threads & Processus C++ Discussion :

FIFO remplie par un signal et depilée dans un thread


Sujet :

Threads & Processus C++

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2010
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2010
    Messages : 68
    Points : 51
    Points
    51
    Par défaut FIFO remplie par un signal et depilée dans un thread
    Bonjour a tous,

    Donc voila tout est dans le titre .
    Je vais quand même détailler un peu.
    Je dois faire du monitoring de processus enfants depuis un processus père. Pour cela mon processus père possède un handler sur le signal SIGCHLD qui signal la fin d'un processus fils. Sur réception du signal il récupère les données de siginfo_t passé en passé par le signal et les mets dans un FIFO.
    Cette FIFO est bloquée et protégée (sémaphore + mutex).
    Pour l'instant je n'ai pas de problème mais je sais que je peux tomber dans un cas de deadlock qui est le suivant.

    une data est poussée dans la fifo, le sémaphore est augmenté à 1.
    la fifo alors en attente sur le sémaphore le réduit a 0, verrouille le mutex récupère la data stockée.

    Par malchance un SGCHLD est levé alors que la FIFO n'a pas relâché le mutex
    Le handler du signal cherche à prendre le mutex de la FIFO déjà verrouiller par le thread
    Le signal reste bloqué car le mutex ne peut être pris et le thread reste bloqué car le signal n'a pas rendu la main.
    -> DEADLOCK

    Ma question des donc la suivante comment puis-je empêcher ce cas?

    P.S. La fifo est un template sur lequel je n'ai pas la main. Je veux dire par la que je ne peux pas m'amuser a bloquer le signal (avant le mutex) puis le débloquer une fois le mutex libéré.

    Merci par avance

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 670
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 670
    Points : 30 447
    Points
    30 447
    Billets dans le blog
    4
    Par défaut
    Salut,

    l'utilisation de mutex est largement plus simple et meilleur avec un objet type guard_lock.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #3
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 182
    Points
    4 182
    Par défaut
    Citation Envoyé par boubouboy Voir le message
    Par malchance un SGCHLD est levé alors que la FIFO n'a pas relâché le mutex
    Si tu es encore dans le handler du SIGCHLD lorsque cela se produit, alors tu n'as pas de crainte à avoir de ce côté là : les signaux suivants du même type vont être bloqués.

    En revanche cela met en avant un défaut de conception car ils vont également être fusionnés ! En conséquence tu ne pourras pas récupérer tous les siginfo_t. Tu devrais revoir ton implémentation et utiliser des signaux temps-réel ou alors un procédé de synchronisation dédié.

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2010
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2010
    Messages : 68
    Points : 51
    Points
    51
    Par défaut
    En revanche cela met en avant un défaut de conception car ils vont également être fusionnés ! En conséquence tu ne pourras pas récupérer tous les siginfo_t. Tu devrais revoir ton implémentation et utiliser des signaux temps-réel ou alors un procédé de synchronisation dédié.
    Le problème avec les signaux temps réel est qu'il faut les envoyer .
    Je fork mon processus père pour lancer des exécutables que je ne contrôle pas ( je ne peux pas rajouter l'envoi d'un SIGRT). Le SIGCHLD est lui envoyé automatique vers le père a la mort du fils, d’où le fait que je me sois orienté de ce coté la.

    Effectivement les signaux fusionneront si je suis dans le handler, je reconnais ne pas encore gérer ce problème (comment avoir les infos pour chaque processus), par contre, je gère la destruction de plusieurs fils sur un SIGCHLD (cas de signaux fusionnés) pour la gestion de la table des processus.

    Que proposez vous comme procédé de synchronisation dédié?

    l'utilisation de mutex est largement plus simple et meilleur avec un objet type guard_lock.
    Je ne pense pas que le lock_gard résolve mon problème de deadlock. A partir du moment ou un signal est reçu par mon process, si mon thread a locker le guard de la fifo je me retrouve dans la même situation de deadlock.
    D'autre part je n'ai pas la main pour modifier le code de ma fifo

    Cordialement,

  5. #5
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 182
    Points
    4 182
    Par défaut
    Citation Envoyé par boubouboy Voir le message
    Effectivement les signaux fusionneront si je suis dans le handler, je reconnais ne pas encore gérer ce problème (comment avoir les infos pour chaque processus)
    Et si tu en trouves une avec les signaux de base, je suis preneur ! Malheureusement je ne pense pas qu'il en existe et je doute que ton problème aie une solution sans action explicite de la part des fils : envoi d'un signal temps réel via sigqueue, modification d'une ressource partagée, écriture dans un fichier / pipe..


    Citation Envoyé par boubouboy Voir le message
    Que proposez vous comme procédé de synchronisation dédié?
    Les constructions qu'on utilise habituellement en programmation concurrentielle : ressource partagée protégée par sémaphores et mutexes (avec action des fils, donc). Je qualifie ici le procédé de synchronisation de dédié car les signaux ne sont pas à la base prévus pour faire de la communication inter-processus.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 15/10/2011, 21h12
  2. Réponses: 7
    Dernier message: 19/08/2011, 08h25
  3. Réponses: 5
    Dernier message: 17/07/2011, 07h51
  4. Réponses: 3
    Dernier message: 28/02/2009, 06h23
  5. Label dans formulaire remplie par du code en indiçant son nom
    Par olivierdz1 dans le forum VBA Access
    Réponses: 2
    Dernier message: 18/01/2008, 09h54

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