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 :

reveiller un thread en attente sur clock_nanosleep


Sujet :

Threads & Processus C++

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

    Informations forums :
    Inscription : Novembre 2010
    Messages : 69
    Points : 53
    Points
    53
    Par défaut reveiller un thread en attente sur clock_nanosleep
    Bonjour a tous,

    J'ai un thread qui est endormi jusqu’à un temps de timeout sur fonction clock_nanosleep().
    Dans le cas ou je souhaite l'interrompre avant la fin. je compte lui envoyer un signal via pthread_kill() avec un signal réel time (SIGRTMIN + n) ou SIGUSR1/2.

    Voici mes questions:
    1 - Est-ce que l'utilisation du signal est le meilleur moyen pour réveiller le thread?
    2 - Si oui, l'utilisation du signal reel time (SIGRTMIN + n), ou SIGUSR est elle bonne?
    3 - Dans le cas ou je lance un SIGINT sur mon programme (ctrl-c) pour le terminer. Commment savoir que mon thread timer est interrompu soit par SIGINT soit par SIGUSR/(SIGRTMIN + n)? dois je avoir une variable via un booleen/enum qui met dit le dernier type de signal reçu?

    Je vous remercie.
    Cordialement,

  2. #2
    Expert éminent
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Décembre 2015
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Décembre 2015
    Messages : 1 562
    Points : 7 628
    Points
    7 628
    Par défaut
    Bonjour,

    1- Pour arrêter un clock_nanosleep() il n'y a que les signaux. Sinon il faut mettre en place un mécanisme de communication plus évolué (pipe, etc...)
    2- tout signal non destructif est utilisable pour cela, donc les SIGRTMIN et les SIGUSR sont tout à fait adaptés
    3- Un signal, ça casse une fonction d'attente parmi les threads qui tournent. On peut utiliser une callback qui détecte le signal attendu et le note. Puis si le clock_nanosleep() retourne un temps restant, on peut vérifier qu'il ne s'agit pas de celui attendu et donc de se remettre en attente du temps restant.
    Attention, si l'application a plusieurs threads cela est nettement plus compliqué ou plus simple (en utilisant mal ou bien les masquages des signaux.)

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Merci pour tes reponses!!

    la methode posix pthread_kill prend le thread id argument, je pensais envoyé le signal via cette méthode sans passer par l’intégration du signal dans le vecteur d'interruption (via la methode sigaction()).
    A ce moment la pas de problème de masquages ? ou je me trompe?

  4. #4
    Expert éminent
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Décembre 2015
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Décembre 2015
    Messages : 1 562
    Points : 7 628
    Points
    7 628
    Par défaut
    En effet pthread_kill est directif. Il faut cependant tenir compte des autres signaux qui se déclencheront sur un thread quelconque qui ne les masque pas.

  5. #5
    Membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Ca marche merci pour cette précision
    Topic resolu !!!

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Bonjour,

    Je me permets de ré-ouvrir ce topic car des questions subsidiaires sont apparus:


    1- Je souhaite envoyer un signal avec la fonction pthread_kill(threadId, Signal-RT) de l'API posix a un thread pour qu'il sorte de la fonction clock_nanosleep(). Que se passe-t- dans le cas ou le thread reçoit le signal alors qu'il n'est pas en attente dans la fonction clock_nanosleep??

    2- Est il préférable modifier l’ignorance ou non de ce signal a chaque fois qu'il rentre dans la méthode clock_nanosleep() :
    - traitement ....
    - Avant clock_nanosleep j'autorise l'interruption via sigmask
    - clock_nanosleep
    - Apres clock_nanosleep j'ignore l'interruption via sigmask
    - traitement ....
    - ... loop

    3- J'etais part dans l'idéee de lancer seulement un pthread_kill sans vecteur d'interruption, mais :
    Est ce que c'est plus "propre" de lancer un pthread_kill pour ce thread "à la volé", ou de créer une routine d'interruption pour ce signal et de gérer les masques des threads en fonction ? Sachant que seulement un seul thread sera affecté par ce signal

    Merci par avance

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Décembre 2015
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Décembre 2015
    Messages : 1 562
    Points : 7 628
    Points
    7 628
    Par défaut
    Citation Envoyé par boubouboy Voir le message
    Que se passe-t- dans le cas ou le thread reçoit le signal alors qu'il n'est pas en attente dans la fonction clock_nanosleep??
    Tant qu'aucune fonction d'aucun thread n'est en attente, il ne se passe rien pour la plupart des signaux (dont USR et RT), le signal reste à l'affut de son déclenchement. La prochaine fonction d'attente quelle qu'elle soit sera débloquée, il en existe de partout, par exemple un printf().
    Citation Envoyé par boubouboy Voir le message
    Est il préférable modifier l’ignorance ou non de ce signal a chaque fois qu'il rentre dans la méthode clock_nanosleep() :
    - traitement ....
    - Avant clock_nanosleep j'autorise l'interruption via sigmask
    - clock_nanosleep
    - Apres clock_nanosleep j'ignore l'interruption via sigmask
    - traitement ....
    - ... loop
    C'est en effet une bonne méthode, on bloque ce signal partout sauf là où on accepte de le recevoir.
    Citation Envoyé par boubouboy Voir le message
    J'etais part dans l'idéee de lancer seulement un pthread_kill sans vecteur d'interruption, mais :
    Est ce que c'est plus "propre" de lancer un pthread_kill pour ce thread "à la volé", ou de créer une routine d'interruption pour ce signal et de gérer les masques des threads en fonction ? Sachant que seulement un seul thread sera affecté par ce signa
    Ça n'est pas la routine qui masque, elle est associée à un mécanisme de masquage. Comme ici le signal est directif, il n'y a rien de spécial à prévoir sur les autres threads.

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Super merci pour ces éclaircissements.

    Je pense que vous avez répondu à toutes mes questions .

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

Discussions similaires

  1. [Thread] Reveiller un thread a partir d'un autre thread d'une autre classe
    Par arnolpourri dans le forum Concurrence et multi-thread
    Réponses: 18
    Dernier message: 11/04/2007, 16h18
  2. [Thread] Petite question sur notify() et wait()
    Par Invité dans le forum Concurrence et multi-thread
    Réponses: 8
    Dernier message: 12/05/2006, 13h13
  3. [Debutant] Un thread qui dessine sur une fenetre ???
    Par Spartan03 dans le forum OpenGL
    Réponses: 6
    Dernier message: 05/04/2006, 21h19
  4. [THREAD] reveiller un thread qui dort
    Par silouane dans le forum Concurrence et multi-thread
    Réponses: 3
    Dernier message: 24/01/2006, 14h39
  5. Mes emails restent en file d'attente sur mon serveur
    Par FredericB dans le forum Réseau
    Réponses: 3
    Dernier message: 26/10/2005, 11h04

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