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 :

Protection de tableaux dans un prog. multi-threadé [Non suivi]


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    45
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 45
    Par défaut Protection de tableaux dans un prog. multi-threadé
    salut à tous,
    j'ai un programme multi-threadé écrit avec la librairie pthread.
    je manipule un tableau qui est accédé simultanèment par les processus mais ce tableau est partitionné de telle sorte qu'un processus ne peut accèder qu'à certains éléments du tableau auxquels les autres processus n'ont pas accès.
    est ce nécessaire de le protèger par un mutex?

    merci

  2. #2
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 397
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 397
    Par défaut
    processus ou threads ?
    Il faudrait savoir...

    Enfin, si le tableau n'est jamais déplacé/redimensionné et que deux threads n'accèdent jamais aux mêmes cases, je ne pense pas qu'il soit nécessaire de protéger le tableau.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 131
    Par défaut
    a mon avis il parle de thread et dit processus par abus de langage (ca m arrive aussi car implicitement je sais que je parle d un processus leger).

    Essaie d utiliser les mutex_lock et mutex_unlock.

    Le plus simple serait de faire un tableau de mutex de la meme taille que ton tableau TAB. Chaque case de TAB aura un mutex qui sera bloquant lors d une ecriture.

  4. #4
    Membre émérite
    Avatar de Freed0
    Profil pro
    Étudiant
    Inscrit en
    Mars 2005
    Messages
    635
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2005
    Messages : 635
    Par défaut
    Bah nan, si il est certain qu'un thread n'ira jamais dans une autre partie du tableau que la sienne, ça sert à rien de placer des mutexs

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    45
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 45
    Par défaut
    merci pour vos réponses.
    effectivement je parle de threads. désolé pour cet abus de langage.
    en fait j'ai un résultat surprenant. j'ai deux threads et ces deux fonctions:
    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
    21
    22
    23
    24
    25
     
    void proceed0() {
       int i, n, id;
       for(id = 0;
            id < PARTITIONS && glob_keep_searching;
            id += 2) {
          for(i = glob_depth_last_dd + 1; i <= glob_depth; i++) {
             n = STATE_TREE_flush1(t, V, i);
             glob_stored1 += n;
             /*  glob_state_count[id][i] += n;  */
          }
       }
    }
    void proceed1() {
       int i, n, id;
       for(id = 1;
            id < PARTITIONS && glob_keep_searching;
            id += 2) {
          for(i = glob_depth_last_dd + 1; i <= glob_depth; i++) {
             n = STATE_TREE_flush1(t, V, i);
             glob_stored1 += n;
             /*  glob_state_count[id][i] += n;  */
          }
       }
    }
    le premier thread appelle proceed0 et le second appelle proceed1. le tableau partagé est glob_state_count. vues l'initialisation et l'incrémentation de id dans les boucles, je suis sur qu'il n'y aura pas de conflit.
    quand je décommente les affectations au tableau mon temps d'exécution passe de 3 minutes à plus d'une demi heure!
    avez vous une idée la dessus?
    je précise que la variable glob_state_count n'est pas utilisée autre part dans le code.

  6. #6
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 397
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 397
    Par défaut
    Attention, glob_stored_1 devrait être protégé.
    Et on ne sait rien sur t et V.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #7
    Membre confirmé
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 131
    Par défaut
    Citation Envoyé par Freed0
    Bah nan, si il est certain qu'un thread n'ira jamais dans une autre partie du tableau que la sienne, ça sert à rien de placer des mutexs
    erf j avais pas fais attention ...
    Ben y a donc rien a faire

  8. #8
    Membre émérite
    Avatar de Freed0
    Profil pro
    Étudiant
    Inscrit en
    Mars 2005
    Messages
    635
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2005
    Messages : 635
    Par défaut
    Bah si t'es sur à 100% qu'il n'y aura pas de conflit entre les 2 threads oui... mais bon pas facile d'être sur à 100%

Discussions similaires

  1. Utilisation du multi-threading dans les jeux vidéos
    Par Dalini71 dans le forum Développement 2D, 3D et Jeux
    Réponses: 11
    Dernier message: 10/10/2011, 12h45
  2. Réponses: 1
    Dernier message: 31/05/2010, 17h27
  3. L'utilisation de synchronized dans une application multi-thread
    Par Tigrounette dans le forum Général Java
    Réponses: 9
    Dernier message: 08/04/2008, 11h52
  4. [Tableaux] recherche dans un tableau multi dimension
    Par kagura dans le forum Langage
    Réponses: 1
    Dernier message: 18/07/2007, 14h27
  5. Réponses: 3
    Dernier message: 06/10/2006, 15h46

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