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 :

pthread dans boucle for et mémoire utilisée


Sujet :

C

  1. #1
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut pthread dans boucle for et mémoire utilisée
    Bonjour,

    Je voulais tester la librairie pthread alors j'ai écris un petit bout de code en m'inspirant des différents tutoriaux disponibles sur le net.
    Il s'agit simplement d'afficher pendant une boucle for la vitesse d'itération par seconde du processeur.

    Avec le code ci-dessous, je constate dans le gestionnaire des tâches que le RAM utilisée par le programme augmente au fur et à mesure du temps et se libère à la fin de la boucle à environ 60Mo de RAM pour une itération stable de 35000 itérations/s.

    Si dans la fonction task ci dessous, je dé commente la ligne qui permet de n'afficher le résultat que tout les 10% de progression alors cette fois ci la RAM va arriver à saturation très rapidement de 0 à 8Go et la vitesse d'itération elle va décroître dans le temps au fur et à mesure que la RAM elle augmente.

    Visiblement, il y a quelque chose dans le concept du thread que je n'ai pas compris.
    Est-ce que quelqu'un est en mesure de m'expliquer ce que je ne fais pas correctement parce que là je sèche total ?

    Merci d'avance pour votre aide.

    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
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    static void *task (void *p_data)
    {
       if (p_data != NULL)
       {
            double *s = p_data;
     
            //if ( s[3]==1 )
                printf("\n iteration/s = %.2f --- progress %.0f %%", s[4], 100*s[1]);
     
            pthread_exit(NULL);
            free(s);
       }
       return NULL;
    }
     
    int main(int argc, char *argv[], char* env[])
    {
        system("title Library");
        system("mode con cols=150 lines=75");
     
        if (logger_on()==TRUE)
        {
            pthread_t t;
     
            double *p = allocate_1D_d(5);
            p[0] = GetTickCount();
            p[1]=0;
            p[2]=0.1;
     
            int i = 0;
            for ( i = 0 ; i<INT_MAX/1000 ; i++ )
            {
                p[1]=1000.*i/INT_MAX;
                p[4] = 1000.*i/(GetTickCount()-p[0]);
     
                if ( p[1] >= p[2] )
                    p[2] += 0.1, p[3]=1;
     
                else p[3]=0;
                pthread_create (&t, NULL, task, (double*)p);
     
            }
            free(p);
            pthread_join (t, NULL);
    }
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  2. #2
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    salut,

    je crois surtout que ce qui limite la consommation de mémoire ici, c'est la vitesse de création d'exécution des threads, et ce qui limite la vitesse d'exécution dans chaque thread, c'est l'affichage avec printf
    moins de printf, plus de threads, plus de mémoire utilisée

  3. #3
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Merci pour ta réponse Bob et là ça devient obscur

    Donc la quantité de création des threads est totalement indépendante du nombre d'itérations de la boucle for dans laquelle il est crée ?
    Effectivement
    -Si le printf est systématique alors la quantité de RAM augmente doucement jusqu'à 70M à 35000 i/s.
    -Si le printf se produit tout les 10% des 100% à atteindre alors la RAM arrive à saturation à 8Go en 3-4s xD. D'ailleurs à l'affichage des 10 premiers % on voit que la vitesse d'itération est de 45000 au lieu de 35000 lorsque le printf est systématique. Et ensuite chaque 10% supplémentaire, la vitesse d'itérations chute totalement.

    Ca m'attriste beaucoup parce que justement, je pensais que les threads allaient palier ce problème, à savoir disposer d'un affichage régulier de valeurs sans que cela ralentisse l’exécution du programme. Ce qui est le cas mais en contre partie d'une utilisation de la RAM outrageuse. Ce qui au final, la rend plus ou moins obsolète à mes yeux, à cet instant et sans plus de connaissance du sujet. Bien que j'imagine qu'il existe d'autres solutions ?!

    Je me pose donc la question suivante, lors d'une copie de fichiers, il y a un thread alloué aux rafraîchissements des valeurs. Il doit donc y avoir un "mécanisme" pour limiter ce phénomène sans pour autant saturer la RAM. En revanche, on perd en performance automatiquement car plus il y a d'affichage à réaliser, plus l’exécution est ralentie. J'imagine donc qu'il doit y avoir un compromis acceptable pour que les deux coexistent.

    As-tu connaissance d'une telle chose ou simplement je n'ai d'autre choix que de faire un printf systématique dans la fonction pour limiter la création de threads et donc la RAM utilisée ?

    EDIT :

    Si je place le pthread_join dans la boucle pour bien libérer les données locales transmises à la fonction task, l'itération est stable à 20000 i/s par contre j'ai toujours un problème de fuite mémoire. La ram utilisée par le programme augmente toujours dans le temps et là je ne comprends pas pourquoi.

    Merci d'avance.
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  4. #4
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    en fait c'était qu'une intuition, ce que tu dis m'oblige à regarder plus en détail ton code
    du coup comme je vois à la fois du GetTickCount() et du pthread_create() je me demandais, tu fais tourner sous quoi, windows ? linux ?
    aussi y'a un certain nombre de fonctions dont on ne peut que supposer de ce qu'elle font, un if pas fermé, donc si tu pouvais mettre un code minimal qu'on puisse compiler ce serait idéal ^^

  5. #5
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Oui c'est bien sous windows !
    Oui effectivement, ça devrait compiler avec ce code minimal :

    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
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
     
    #include <windows.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <limits.h>
    #include <time.h>
    #include <math.h>
    #include <pthread.h>
     
    static void *task (void *p_data)
    {
       if (p_data != NULL)
       {
            double *s = p_data;
     
     
                if ( s[1] >= s[2] )
                    s[2] += 0.1, s[3]=1;
     
                else s[3]=0;
     
            if ( s[3]==1 )
                printf("\n iteration/s = %.2f --- progress %.0f %%", s[4], 100*s[1]);
     
            pthread_exit(NULL);
     
       }
       return NULL;
    }
     
    int main(int argc, char *argv[], char* env[])
    {
            pthread_t t;
     
            double *p = (double*)malloc(5*sizeof(double));
            p[0] = GetTickCount();
            p[1]=0;
            p[2]=0.1;
     
            int i = 0;
            for ( i = 0 ; i<INT_MAX/1000 ; i++ )
            {
                p[1]=1000.*i/INT_MAX;
                p[4] = 1000.*i/(GetTickCount()-p[0]);
     
                pthread_create (&t, NULL, task, (double*)p);
                pthread_join (t, NULL);
            }
            free(p);
            return 0;
    }
    Merci d'avance !
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  6. #6
    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,

    La présence ou non d'un printf() change fortement les choses.
    Les printf() sont un point de passage commun, ils sont protégé par un mutex voire un semaphore.
    Les threads sans printf() ne font qu'enchaîner des appels système puis s'arrêtent quasi-immédiatement, libérant leur mémoire.
    Les threads avec printf() tentent de prendre le mutex et se retrouvent bloqués en attente du printf() des autres threads
    La mémoire consommées par un thread c'est essentiellement pour sa pile (1MO à ma connaissance sous Windows), donc tous ces MO s'empilent et ne sont libérés que bien plus tard (il faut des dizaines de µs...)

  7. #7
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Citation Envoyé par dalfab Voir le message
    Bonjour,

    La présence ou non d'un printf() change fortement les choses.
    Les printf() sont un point de passage commun, ils sont protégé par un mutex voire un semaphore.
    Les threads sans printf() ne font qu'enchaîner des appels système puis s'arrêtent quasi-immédiatement, libérant leur mémoire.
    Les threads avec printf() tentent de prendre le mutex et se retrouvent bloqués en attente du printf() des autres threads
    La mémoire consommées par un thread c'est essentiellement pour sa pile (1MO à ma connaissance sous Windows), donc tous ces MO s'empilent et ne sont libérés que bien plus tard (il faut des dizaines de µs...)
    Merci dalfab pour ta réponse. Est ce que tu suggères que mon thread devrait également utiliser un mutex pour s'assurer qu'il libère la mémoire avant d'arriver au prochain printf ?

    La présence ou non d'un printf() change fortement les choses.
    Est-ce que tu parles de la présence d'un printf au sein d'une fonction utilisée par le thread uniquement ou en général même dans le corps du programme ?

    Question subsidiaire si tu en connais la réponse : est-ce que de manière générale l'affichage de valeur printf ou pas ( interface graphique QT, SDL...) va nécessiter (pour des raisons techniques dont j'ignore les enjeux) un mutex également ou bien ceci est propre à la fonction printf ?

    Merci d'avance.
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  8. #8
    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
    C'est propre à toute fonction ayant potentiellement un problème de réentrance.
    Pour les UI il est souvent imposé que tous les appels doivent se faire sur un unique thread, elles évitent ainsi de créer ce mécanisme de protection.
    Sinon la plupart des fonctions de la bibliothèque sont naturellement réentrantes.
    exemples :
    printf(), scanf(), fprintf(), strdup(), strtok(), malloc(), free() nécessitent une protection
    strlen(), sscanf(), memcpy() n'en ont pas besoin.

  9. #9
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Merci pour ta réponse.
    Concrètement, est-ce qu'il y a quelque chose à faire pour palier ce problème ?

    Merci d'avance.
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  10. #10
    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
    Un problème, quel problème?

  11. #11
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    "l’inter-entrelacement" des printf pendant l’exécution du thread.
    De ce que je constate, le thread n'attend pas la fin de "l’exécution" du printf pour lancer le suivant ce qui provoque dans l'invite de commande quelque chose de relativement erratique.
    Je ne sais pas si mes termes sont corrects mais je pense que tu comprends ce que je décris comme phénomène.
    En plus de fortement scintiller, il y a des reste de printf n-i qui s'incrustent par dessus celui du printf n.

    Par exemple, j'ai réécris la fonction copie de fichier.
    Je souhaite afficher certaines informations comme :
    Le chemin du fichier en cours de copie
    La destination du fichier en cours de copie
    La progression de la copie en % avec le vitesse de copie
    Le temps restant.

    Admettons que cet affichage occupe 4 lignes dans l'invite de commande. Je crée donc une fenêtre de 4 lignes.
    Le thread lui va afficher ces informations avec ce que je décris plus haut.

    Pour un code minimal, admettons la fonction file_copy et file_copy_thread qui est la fonction appelée par le thread dans la fonction file_copy.
    Je précise que tous les tests de pointeurs post allocations ne sont pas faits on purpose, ce n'est pas définitif, ce n'est que de la fainéantise pour le moment et ce jusqu'à ce que je me sois assuré que tout est fonctionnel.

    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
     
    static void *file_copy_thread(void *p_data)
    {
       if (p_data != NULL)
       {
            t_file_copy_thread *fct = p_data;
            double current_size = fct->total_written_byte*(fct->file_unit->coeff);
            double t = (GetTickCount()-fct->t0)/1000.;
            double speed = fct->total_written_byte/(1024.*1024.*t);
            double progress = 100.*fct->total_written_byte/fct->f_src_size;
            if ( fct->total_written_byte%(1024*1024*10) == 0 )
            {
                t_time *time_left = file_copy_time_left(speed, ((fct->f_src_size-fct->total_written_byte)/1024*1024));
                printf("\n Copying file");
                printf("\n -->From     : %s", fct->src);
                printf("\n -->To       : %s", fct->dst);
                printf("\n -->Progress : %.2f/%.2f %s [%.2f%%]", current_size, fct->f_src_size*fct->file_unit->coeff, fct->file_unit->unit, progress);
                printf("\n -->Speed    : %.2f MByte/s",speed);
                printf("\n -->Time left: "); time_display_line(time_left);
                time_destroy_structure(time_left);
                fflush(stdout);
            }
       }
    }
    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
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    /** *********************************************************************************************************************************************************************************************************************************
     * \fn t_boolean file_copy(const char *src, const char *dst)
     ***********************************************************************************************************************************************************************************************************************************
     * \brief Copies a file
     ***********************************************************************************************************************************************************************************************************************************
     * \param      src[const char*] &rarr; Path to the source file
     * \param      dst[const char*] &rarr; Path to the destination file
     * \return     copy_status[t_boolean] &rarr; Status of the function after its execution
     *
     **********************************************************************************************************************************************************************************************************************************/
    t_boolean file_copy( const char *src, const char *dst )
    {
        t_boolean copy_status = FALSE;
        if ( src && dst )
        {
            t_uint64 f_src_size = file_length( src );
            if ( file_exist( src ) == TRUE && file_exist( dst ) == FALSE )
            {
                FILE *f_src = NULL; FILE *f_dst = NULL;
                if ( ( f_src = file_open( src, "rb" ) ) && ( f_dst = file_open( dst,"wb" ) ) )
                {
                    double t0 = GetTickCount();
                    t_file_unit *file_unit = NULL;
                    if ( ( file_unit = file_copy_get_size_unit( src ) ) )
                    {
                        pthread_t t;
                        t_uint64 read_byte, written_byte, total_written_byte=0;
                        char *buffer = NULL;
                        if ( ( buffer = allocate_1D_c( MBYTE ) ) )
                        {
                            t_file_copy_thread *fct = file_copy_thread_init( dst, file_unit, f_src_size, src, t0, 0 );
                            while ( 0 < ( read_byte = fread ( buffer, BYTE, MBYTE, f_src ) ) )
                            {
                                written_byte = fwrite( buffer, read_byte, 1, f_dst );
                                total_written_byte += written_byte*read_byte;
                                file_copy_thread_update( fct, total_written_byte );
                                pthread_create (&t, NULL, file_copy_thread, (t_file_copy_thread*)fct );
                                pthread_join( t, NULL );
                            }
                            file_copy_thread_update( fct, total_written_byte );
                            pthread_create( &t, NULL, file_copy_thread_end, (t_file_copy_thread*)fct) ;
                            pthread_join( t, NULL );
                            pthread_exit(t);
                            deallocate_1D_c( buffer );
                        }
                        else fprintf(logger, "\nfile.h::file_copy --> allocate_1D_c returned NULL");
                    }
                    else fprintf(logger,"\nfile.h::file_copy --> file_copy_get_size_unit returned NULL");
                    file_close( f_src );
                    file_close( f_dst );
                }
                else
                {
                    if ( !f_src )
                        fprintf(logger,"\nfile.h::file_copy --> f_src=file_open returned NULL");
                    if ( !f_dst )
                        fprintf(logger,"\nfile.h::file_copy --> f_dst=file_open returned NULL");
                }
            }
            else fprintf(logger,"\nfile.h::file_copy --> \"%s\" doesn't exist or \"%s\" already exists", src, dst);
     
            t_uint64 f_dst_size = file_length( dst );
            if ( f_dst_size == f_src_size )
                copy_status=TRUE;
        }
        else
        {
            if( !src )
                fprintf(logger,"\nfile.h::file_copy --> src is NULL");
            if( !dst )
                fprintf(logger,"\nfile.h::file_copy --> dst is NULL");
        }
        return copy_status;
    }
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  12. #12
    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
    Le problème en effet c'est que quand il y a plusieurs threads, il y a des problèmes de cohérence des résultats.
    printf() ne fait que se protéger des incohérences de gestion de ses données.
    Il existe des mécanismes particuliers pour synchroniser les threads ; C'est pourquoi les UI imposent souvent d'être sur un thread unique. Le plus "simple" est d'utiliser des threads-workers a qui on demande des actions, les résultats sont ensuite récupérés par le thread principal qui est le seul a faire des affichages.
    La synchronisation peut se faire par exemple par l'utilisation des std::promise.
    Si on veut afficher une progression, chaque thread doit régulièrement envoyer son état au thread-afficheur.

    Il est aussi possible de "protéger" une séquence d'affichage mais cela casse souvent l'intérêt du multi-threading si la séquence est fréquente ou longue . Exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    std::mutex monMutex;
     
    void fonctionProtegee( std::string const& str ) { // fonction appelable par tous les threads
       std::lock_guard<std::mutex> gardien(monMutex); // gardien protège tout le bloc qui suit grace au  mutex
       // ... sequence protegee ...... qui peut utiliser printf ... chacun attend que le précédent ait terminé ...
       std::cout << str;
    }

  13. #13
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Merci pour tes explications.
    Effectivement, j'ai tenté d'implémenter le mutex en me basant sur des exemples en plaçant le lock et l'unlock sur la zone critique contenant le printf mais je n'ai pas vu de différence dans l'affichage car j'ai probablement mal compris ce qui devait être fait. A méditer de mon côté.
    Et si tu me dis que cela casse l'intêret et on peut le comprendre dans la mesure où cela bloque d'une certaine manière l'execution du thread. A la rigueur ce ne serait pas bien gênant car les opérations de calculs ne se font pas dans la fonction utilisée par la thread, ce n'est que de l'affichage donc pas d'altération des performances ?. Et normalment le thread lui, ne bloque pas l'execution du reste du code, c'est son intêret.

    Je vais me renseigner sur les thread workers, en espérant que cette notion existe avec la librairie pthread.

    Cordialement.
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  14. #14
    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
    @dalfab, c'est du C.

    Je n'ai pas bien saisi ton cas d'utilisation, à quoi servent tes threads au final ? Car s'il s'agit d'afficher la progression d'une seule et unique tâche, un seul thread suffit (en plus de celui qui réalise la tâche).

  15. #15
    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
    Ah oui Matt, en langage C c'est plutôt :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    pthread_mutex_t monMutex = PTHREAD_MUTEX_INITIALIZER;
     
    void fonctionProtegee( const char *str ); // gardien protège tout le bloc qui suit grace au  mutex
       pthread_mutex_lock( &monMutex );
       // ... sequence protegee ...... qui peut utiliser printf ... chacun attend que le précédent ait terminé ...
       printf( "%s" , str );
       pthread_mutex_unlock( &monMutex );
    }

  16. #16
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Citation Envoyé par Matt_Houston Voir le message
    @dalfab, c'est du C.

    Je n'ai pas bien saisi ton cas d'utilisation, à quoi servent tes threads au final ? Car s'il s'agit d'afficher la progression d'une seule et unique tâche, un seul thread suffit (en plus de celui qui réalise la tâche).
    Je n'utilise qu'un thread mais je ne crois pas avoir parlé d'en utiliser plusieurs.

    En somme tout ce que je veux, c'est un thread qui me permet d'afficher certaines données sans avoir à attendre chaque tour de boucle de la fontion qui appelle le thread. D'où l'utilisation d'un thread.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Fonction affichage
       traitement affichage
    Fin affichage
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Fonction copy
       boucle
          traitement
          thread(Fonction affichage)
       Fin boucle
    Fin copy
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  17. #17
    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
    Ce que tu fais là, c'est à chaque tour de boucle calculer un résultat puis spawner un thread (ça coûte cher !) qui va accéder à la zone mémoire où tu as mis le résultat, sans aucun mécanisme de synchronisation entre le producteur main et les consommateurs créés via pthread_create. Non seulement ton algo n'est pas vraiment parrallélisé mais tu as des race conditions en vrac.

    Je me dois également de mentionner les erreurs annexes les plus sérieuses :
    • code exécutable placé après la terminaison du thread (« heureusement » au final car le thread n'est pas propriétaire du bloc passé à free, et il est partagé par tout le monde) :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
          pthread_exit(NULL);
          free(s);
    • appel à free avant la terminaison d'un thread sur un bloc qu'il référence (comportement indéterminé) :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
          free(p);
          pthread_join (t, NULL);
    • perte de contrôle des threads créés auparavant : tu utilises le même handle pour tous les appels à pthread_create, tu ne sais donc pas ce qu'il advient d'eux (et tu join seulement sur le dernier thread créé).


    Ce que tu cherches à faire - je pense - c'est créer un seul thread avant la boucle principale qui va venir régulièrement (comprendre : dans sa propre boucle) lire le bloc mémoire où sera stocké le résultat. Tu dois utiliser quelque chose pour synchroniser l'accès à ce bloc.
    Lorsque le travail est terminé, tu dois prévenir le thread « d'affichage » qu'il peut arrêter sa boucle et terminer. Tu peux utiliser pour ce faire un mutex et pthread_mutex_trylock, je peux te montrer un exemple si besoin.

  18. #18
    Membre émérite
    Homme Profil pro
    sans emploi
    Inscrit en
    Janvier 2014
    Messages
    539
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : sans emploi
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2014
    Messages : 539
    Points : 2 601
    Points
    2 601
    Par défaut
    Citation Envoyé par darkwall_37 Voir le message
    Je n'utilise qu'un thread mais je ne crois pas avoir parlé d'en utiliser plusieurs.
    Bonjour,
    Ton programme aura au moins 2 threads, celui qui exécute le main, celui que tu crées dans la boucle. C'est extrêmement maladroit de faire un create dans un boucle immédiatement suivi d'un join → le thread principal (celui de main) va créer un thread (une opération lourde) puis le join va le faire se mettre en attente de la fin du thread secondaire. Ce que tu fais sera intrinsèquement séquentiel.

    L'idée quand on utilise les pthreads est d'en créer quelques uns pour partager le travail et les réutiliser, pas d'en créer un à chaque nouveau travail et de le libérer ensuite.

    Ce que tu fais là est utiliser un tournevis pour planter un clou, c'est pas que ça ne fonctionne pas mais c'est pas adapté.
    Citation Envoyé par darkwall_37 Voir le message
    En somme tout ce que je veux, c'est un thread qui me permet d'afficher certaines données sans avoir à attendre chaque tour de boucle de la fontion qui appelle le thread. D'où l'utilisation d'un thread.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Fonction affichage
       traitement affichage
    Fin affichage
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Fonction copy
       boucle
          traitement
          thread(Fonction affichage)
       Fin boucle
    Fin copy
    L'idée serait plus :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    fonction partage_boulot( taille_boulot )
      pour i de 0 à taille_boulot/(nombre_thread+1)
        thread(i*nombre_thread, (i+1)*nombre_thread)
    Si tu veux un affichage séquentiel alors un des moyens est qu'au lieu d'afficher les données directement un thread (pourquoi pas le principal) s'occupe de récupérer les données et de les afficher dans l'ordre une fois le boulot fini.

  19. #19
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Merci pour ta réponse Matt_Houston
    Justement, ce que je ne comprends pas et tes connaissances permettent de le pointer du doigt, c'est comment afficher la mise à jour des valeurs avec un thread crée hors de la boucle de travail.
    C'est un mécanisme que je n'ai pas eu l'occasion de voir dans des tutoriels que j'ai pu survoler je dois l'admettre.
    Effectivement, maintenant que je comprends mieux ce que fais le thread avec tes explications, j'appréhende mieux le phénomène de montée en RAM que j'ai pu rencontrer ainsi que l'entrelacement des printf.
    Et je comprends que le code que j'ai écris est absurde pour mon besoin.

    Techniquement, je ne vois pas comment demander au thread désormais crée hors de la boucle de se "reveiller" pour afficher les valeurs mises à jour pendant l'execution de la boucle de traitement.
    A moins d'utiliser un mutex dans la boucle de traitement qui serait relié au thread d'affichage et qui reveille ce thread lorsqu'il reçoit le message d'unlock ?

    Je t'avoue comme je ne connais pas très bien le sujet, je suis probablement en train de dire n'importe quoi...
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

  20. #20
    Membre confirmé
    Homme Profil pro
    Etudiant administrateur systèmes et réseaux
    Inscrit en
    Octobre 2007
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Etudiant administrateur systèmes et réseaux

    Informations forums :
    Inscription : Octobre 2007
    Messages : 731
    Points : 467
    Points
    467
    Par défaut
    Citation Envoyé par picodev Voir le message
    Bonjour,
    Ton programme aura au moins 2 threads, celui qui exécute le main, celui que tu crées dans la boucle. C'est extrêmement maladroit de faire un create dans un boucle immédiatement suivi d'un join → le thread principal (celui de main) va créer un thread (une opération lourde) puis le join va le faire se mettre en attente de la fin du thread secondaire. Ce que tu fais sera intrinsèquement séquentiel.

    L'idée quand on utilise les pthreads est d'en créer quelques uns pour partager le travail et les réutiliser, pas d'en créer un à chaque nouveau travail et de le libérer ensuite.

    Ce que tu fais là est utiliser un tournevis pour planter un clou, c'est pas que ça ne fonctionne pas mais c'est pas adapté.


    L'idée serait plus :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    fonction partage_boulot( taille_boulot )
      pour i de 0 à taille_boulot/(nombre_thread+1)
        thread(i*nombre_thread, (i+1)*nombre_thread)
    Si tu veux un affichage séquentiel alors un des moyens est qu'au lieu d'afficher les données directement un thread (pourquoi pas le principal) s'occupe de récupérer les données et de les afficher dans l'ordre une fois le boulot fini.
    Merci pour ta réponse picodev.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Si tu veux un affichage séquentiel alors un des moyens est qu'au lieu d'afficher les données directement un thread (pourquoi pas le principal) s'occupe de récupérer les données et de les afficher dans l'ordre une fois le boulot fini
    Ce que je souhaite justement c'est avoir l'état d'avancement en temps réel de l'éxecution de la copie. Si j'ai bien compris ce que tu voulais dire par ta phrase qui suggère donc l'affichage post traitement tel un fichier de log par exemple ?
    UNE REPONSE UTILE : &|| UN PROBLEME RESOLU :

Discussions similaires

  1. Réponses: 9
    Dernier message: 15/09/2006, 20h08
  2. [débutant] Pb dans boucle For
    Par Sam 069 dans le forum Access
    Réponses: 2
    Dernier message: 11/09/2006, 14h10
  3. Réponses: 3
    Dernier message: 04/08/2006, 20h24
  4. problème dans boucle for de lecture de fichier ini
    Par chourmo dans le forum Delphi
    Réponses: 3
    Dernier message: 06/07/2006, 10h31
  5. [JLabel] JLabel dans boucle for
    Par clairenes dans le forum AWT/Swing
    Réponses: 2
    Dernier message: 06/01/2006, 01h47

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