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

C++ Discussion :

multithreading et recursivité


Sujet :

C++

  1. #41
    Membre expérimenté
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 192
    Par défaut
    Un mutex, c'est juste un objet tout seul qui possède un nom, et qui ne peut être possédé que par un thread. C'est tout ce que c'est. Après, on peut l'attendre, le prendre, le rendre... Rien de plus, et je pense que ça permet justempent de bien s'adapter à ton cas particulier (il s'est pas brossé les dents mon algo ?)

  2. #42
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    ok, ma question n'etait pas clair, j'essaie de preciser :

    j'ai une variable globale qui est un objet "mutex"
    dans chaque thread, j'ai une variable locale qui est de type "lock", qui est associé a l'objet mutex sus defini

    quand je touche a qqchose qui doit etre protégé, je bloque mon objet lock, puis je le debloque ensuite..

    donc je dois me planter qq part, car mon mutex n'est pas explicitement associé a ma pile. pourtant, ca marche :-)

  3. #43
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    voici un exemple simple dont je me suis inspiré :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
     
    #include <boost/thread/thread.hpp>
    #include <iostream>
     
    int count = 0;
    boost::mutex mutex;
     
    void increment_count()
    {
       boost::mutex::scoped_lock lock(mutex);
       std::cout << "count = " << ++count << std::endl;
    }
     
    int main(int argc, char* argv[])
    {
       boost::thread_group threads;
       for (int i = 0; i < 10; ++i)
          threads.create_thread(&increment_count);
       threads.join_all();
    }
    ici, c'est bien evidemment count qui doit etreprotégé, mais a aucun moment on ne dit "le mutex est la pour proteger count", on bloque un point c'est tout...

  4. #44
    Membre expérimenté
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 192
    Par défaut
    Selon l'utilisation que tu en fais, c'est toi qui intrinsèquement le lies à une ressource (en bloquant le mutex dès que tu accède à la ressource). Donc ça marche, bien entendu!
    Mais peut-être qu'avec la librairie que tu utilises il est possible de le faire explicitement, je ne la connais pas, mais on n'a pas forcément besoin.
    Utiliser des outils génériques est une bonne chose pour éviter des bugs, mais je pense qu'il ne faut pas tomber dans un moule de cas d'utilisation prédéfinis si on veut faire de l'optimisation...

  5. #45
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    oui, en fait, je viens de comprendre le degre de debilité de ma question... passons, passons... désolé !!

  6. #46
    Membre expérimenté
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 192
    Par défaut
    C'est la chaleur, on est tous un peu en surchauffe...

  7. #47
    Membre Expert
    Avatar de Eusebe
    Inscrit en
    Mars 2006
    Messages
    1 992
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 992
    Par défaut
    Moi je pense que deux mutex sont nécessaires :
    - un mutex pour gérer l'attente de remplissage de la pile (si elle est vide et que d'autres threads travaillent encore) ;
    - un mutex pour protéger l'accès à la pile.

    Cela éviterait de bloquer un thread qui veut empiler quelque chose parce qu'un autre thread bloque la pile parce qu'elle est vide

    L'algorithme serait le suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    Prendre le mutex d'attente
        Tant que l'on a pas de travail et que des thread bossent
            Prendre le mutex de la pile
                si la pile n'est pas vide
                    dépiler
                    incrémenter NT
                fin du si
            Liberér le mutex de la pile
            Si on a pas de travail, attendre x ms
         Fin Tant que
    Libérer le mutex d'attente
    (travail...)
    Prendre le mutex de la pile
        empiler (si besoin)
        décrémenter NT
    Libérer le mutex de la pile
    Comme ça, on a un seul thread qui regarde si la pile est vide ou pas. L'attente de x ms si ce thread n'a pas de travail est là pour éviter qu'il bouffe trop de temps cpu à faire sa boucle...

  8. #48
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    oui, j'avais pense a un mutex en plus, en gros :

    pour ecrire dans la pile -> prendre le mutex de la pile

    pour lire la pile -> prendre le mutex de la pile ET un mutex qui est bloqué quand la pile est vide.

    mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...

  9. #49
    Membre Expert
    Avatar de Eusebe
    Inscrit en
    Mars 2006
    Messages
    1 992
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 992
    Par défaut
    Citation Envoyé par jobherzt
    mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...
    Là, je ne te suis encore plus du tout

    Est-ce que le pseudo-algorithme que j'ai proposé ne te conviendrais pas ?

  10. #50
    Membre expérimenté
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 192
    Par défaut
    Citation Envoyé par jobherzt
    mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...
    en effet! Ca ne doit pas être possible! La solution d'Eusebe parait pas mal du tout (reste à paramétrer le temps d'attente pour ne pas attendre trop longtemps en ne consommant pas trop de cpu).

  11. #51
    Membre expérimenté
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 192
    Par défaut
    Et en utilisant un sémaphore au lieu d'un mutex pour l'attente ?
    Les sémaphores peuvent être incrémentés ou décrémentés par n'importe quel thread. On l'incrémente quand on met un élément dans la pile, quand on enlève on l'attend au besoin et on le décrémente . Ca paraît mieux que la solution d'Eusebe, il n'y a pas d'attente.
    (Les sémaphores, c'est comme les mutex, mais pas unitaires : il n'est plus dispo quand le nombre qui lui correspond est nul, et il est dispo dès que ce nombre est strictement positif, sans limite supérieure (enfin, théoriquement). On peut lui piquer une unité s'il en a, sinon on doit attendre, et on peut lui en ajouter une, et ce à partir de n'importe quel thread)

  12. #52
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    ca serait pas mal, je vais regarder !!

    si, Eusebe, ca me semble pas mal, mais ca bloque l'acces a la pile pendant X secondes, ca peut poser probleme, non ?? je vais reflechir a tout ca a tete reposé..

    et n'oublions pas que pour l'instant ca marche, meme si ce coup de la boucle qui tourne en rond n'est peut etre pas terrible.. je vais deja faire des tests pour voir si je neperds pas en perf !

  13. #53
    Membre Expert
    Avatar de Eusebe
    Inscrit en
    Mars 2006
    Messages
    1 992
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 992
    Par défaut
    Citation Envoyé par jobherzt
    si, Eusebe, ca me semble pas mal, mais ca bloque l'acces a la pile pendant X secondes, ca peut poser probleme, non ?? je vais reflechir a tout ca a tete reposé..
    Non, ça ne bloque pas l'accès à la pile pendant x secondes. La pile est libre la plupart du temps, ça évite juste que la boucle tourne trop en rond.

    Mais en effet, comme le propose borisd, un sémaphore pourrait peut-être t'aider (à étudier )

  14. #54
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    comme il faut bien que la fonction rechercher donne des resultats, je remonte ce post pour dire que la librairie boost_thread offre une classe condition qui facilite le schmilblick.

    le principe : je declare un objet estLibre de type classe condition en global.

    si la pile est vide, j'ai une methode :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    estLibre.wait(verrou)
    ou verrou est un verrou sur un mutex. cette fonction libere le mutex (il fallait qu'il soit verrouillé) et met le thread en pause. ensuite, des que quelqu'un met un truc dans la pile, il envoie un :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    estLibre.notify_all()
    qui, comme son nom l'indique, signale aux autres threads qu'il y a de nouveau du taf .. en gros, tous les threads qui etaient en wait se remettent en route, et l'un d'entre eux prend directement le verrou, et les autres attendent tout a fait normalement que le verrou se libere pour agir.

    ca me force quand meme a faire quelque test un peu lourd, mais c'est une solution assez "propre" !!

    encore merci a tous pour vos precieux conseils !

    du coup, ca m'oblige quand meme a rajouter des test un peu redondants,

  15. #55
    Membre éprouvé Avatar de uriotcea
    Homme Profil pro
    Ingénieur / physicien
    Inscrit en
    Septembre 2003
    Messages
    1 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur / physicien
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 301
    Par défaut
    bonjour,

    Si tu es noyé dans la complexité des threads as-tu songé à regarder MPI.
    Ca permet de paralleliser une application de maniere simple. C'est destiné aux calculs scientifique et c'est completement free

    Didier

  16. #56
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    je decouvre en effet la joie du debuggage multi thread, et la merveilleuse part d'aleatoire que ca introduit...

    sauf erreur, MPI sert a echanger des messages entre plusieurs sous processus, donc il faut deja avoir paralleliser le schmilblick pour l'utiliser, et ca s'applique surtout dans un contexte de cluster, pour l'instant je n'ai "qu'un" bi processeur a ma disposition :-)

  17. #57
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Par défaut
    Citation Envoyé par jobherzt
    sauf erreur, MPI sert a echanger des messages entre plusieurs sous processus, donc il faut deja avoir paralleliser le schmilblick pour l'utiliser, et ca s'applique surtout dans un contexte de cluster, pour l'instant je n'ai "qu'un" bi processeur a ma disposition :-)
    Eh oui, c'est plus cluster parce que communication par message et non par mémoire partagée, mais même avec un bi-proc, il n'y a pas de souci, tu parallélises et tu fais un mpirun avec un nombre de threads supérieurs à 1, et c'est bon, quand tu passeras à un cluster, il y aura moins de bugs.

  18. #58
    Membre éprouvé Avatar de uriotcea
    Homme Profil pro
    Ingénieur / physicien
    Inscrit en
    Septembre 2003
    Messages
    1 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur / physicien
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 301
    Par défaut
    cluster ou PC multiprocesseur, c'est totalement transparent pour MPI. En effet il faut juste lui indiquer le nombre de process et leur repartition. J'ai essayé il y a quelque temps sur un bi-pro: Gain=2

  19. #59
    Membre émérite
    Inscrit en
    Janvier 2005
    Messages
    711
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 711
    Par défaut
    par curiosité, quel serait l'avantage pour moi, par rapport a du multithread ? en ajoutant qu'il ya des données partagées entre les threads qui doivent etre accessible en temps reels...

    a terme, si je passe sur un cluster, ce sera avec de la memoire partagée et un systeme type Mosix pour repartir les threads de maniere transparente sur les nodes du cluster. pensez vous que j'ai malgré tout interet a utiliser MPI ?

  20. #60
    Membre éprouvé Avatar de uriotcea
    Homme Profil pro
    Ingénieur / physicien
    Inscrit en
    Septembre 2003
    Messages
    1 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur / physicien
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 301
    Par défaut
    J'y voyais seulement une facilté à metre en oeuvre. Maintenant j'avoue ne pas assez connaitre ce produit pour dire comment il gere la memoire partagé
    désolé

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 4 PremièrePremière 1234 DernièreDernière

Discussions similaires

  1. Iteration VS recursivité
    Par yacinechaouche dans le forum C
    Réponses: 40
    Dernier message: 16/11/2012, 11h52
  2. [WinAPI C++] MultiThreading et PostMessage
    Par Gruik dans le forum Windows
    Réponses: 7
    Dernier message: 29/03/2004, 15h58
  3. [WinAPI C++] MultiThreading?
    Par Gruik dans le forum Windows
    Réponses: 2
    Dernier message: 25/03/2004, 00h08
  4. [Win32]App multithread
    Par billyboy dans le forum Windows
    Réponses: 5
    Dernier message: 25/09/2003, 09h57
  5. Multithreading sous HP Ux 11
    Par pykoon dans le forum Autres éditeurs
    Réponses: 1
    Dernier message: 18/10/2002, 23h36

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