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 :

thread : gérer les priorités


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre très actif
    Homme Profil pro
    Inscrit en
    Août 2013
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Août 2013
    Messages : 274
    Par défaut thread : gérer les priorités
    Bonjour à tous,

    Je viens de voir les threads en C. J'ai lancé 2 threads, dont l'un écrivait sur le terminal la lettre A, puis le second la lettre B. J'avais donc un mélange sur le terminal de A et B ce qui est logique. Je souhaite maintenant gérer des priorités avec cet exemple pour m'entrainer à gérer les threads. Ainsi le résultat voulu doit etre que des lettres A, puis que des lettres B sur le terminal. Mais je n'arrive pas en gérant la variable sched_priority à modifier le thread qui doit etre prioritaire.
    Dans mon code le thread t1 qui dit A, est prioritaire par rapport au thread qui dit B. mais si je change la priorité :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    sched1.sched_priority = 2; //decide des priorités 1>2
    sched2.sched_priority = 1;
    c'est toujours le thread t1 qui affiche son texte en premier. alors que j'aimerais que ce soit t2 qui soit prioritaire. Avez vous une idée du pourquoi?

    voici mon code:
    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
     
    void* DireB(){
    	for (int i = 0; i < 2000; ++i)
    	{
    		printf("B\n");
    	}
    }
     
    void* DireA(){
    	for (int i = 0; i < 2000; ++i)
    	{
    		printf("A\n");
    	}
    }
     
    int main(){
    	pthread_attr_t attr1,attr2; 		//attributs pour gérer les priorités
    	struct sched_param sched1,sched2;	//gestionnaire de priorité
     
    	sched1.sched_priority = 1; //decide des priorités 1>2
    	sched2.sched_priority = 2;
    	pthread_t t1,t2;
     
    	pthread_attr_init(&attr1); 		//initialise les attributs par défauts
    	pthread_attr_init(&attr2);
     
    	sched_setscheduler(0, SCHED_RR, &sched1); //on instancie les gestionnaires
    	sched_setscheduler(0, SCHED_RR, &sched2);
     
    	pthread_attr_setschedparam(&attr1,&sched1); //on initialise les attributs en fonction des gestionnaires
    	pthread_attr_setschedparam(&attr2,&sched2);
     
     
    	pthread_create(&t1, &attr1, DireA, NULL); //on lance les threads
    	pthread_create(&t2, &attr2, DireB, NULL);
    	pthread_join(t1,NULL); 
    	pthread_join(t2,NULL); 
     
    	return 0;
    }
    Merci d'avance pour votre aide

  2. #2
    Membre Expert
    Inscrit en
    Mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 1 431
    Par défaut
    Pourquoi invoquer sched_setscheduler ici ? A contrario, il manque sans doute des appels à pthread_attr_setschedpolicy.

    Quoiqu'il en soit, définir la priorité n'a de sens que lorsque les ressources sont limitées. Si ton processeur possède plusieurs cœurs (comme c'est très probablement le cas s'il s'agit d'un PC moderne) chaque thread sera dispatché sur un cœur dédié pour une exécution parallèle qu'importe sa priorité.

  3. #3
    Expert confirmé
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Décembre 2015
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    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 599
    Par défaut
    Bonjour,

    La priorité ne sert pas à dire qui sera fait en premier.
    Déjà son sens dépend si le logiciel est exécuté dans un système Temps-réel (qui doit garantir des temps de réactions) ou MultiThread (comme Windows ou Unix qui doit garantir qu'un thread même très prioritaire ne bloque pas le système). Ensuite il dépend aussi du type de partage (round-robin, Highest, CPU quantum, ...). Et le comportement est aussi lié au nombre de threads du processeur.
    La priorité n'a de sens qu'au moment où il y a conflit d'accès au CPU.
    Si les threads sont simultanément dans l'état "Ready" ET qu'il n'y pas assez de Thread processeur disponibles, alors la priorité va arbitrer lequel prend le CPU (et dans certains cas, le moins prioritaire peut être choisi!)
    Si 2 threads appellent une fonction système tout est possible (et ici tu appelles printf()), le noyau va donner une "préférence" au plus prioritaire au moment des conflits, mais le moins prioritaire peut tout à fait se terminer avant le plus prioritaire.
    Par être sûr qu'un thread exécute un code après un autre, il faut utiliser des synchronismes (rendez-vous, sémaphore, condition variable, ...)

  4. #4
    Expert confirmé
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 527
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 527
    Par défaut
    salut vite fait bien fait pas certain que ça arrange le problème mais ces instructions là

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    sched1.sched_priority = 1; //decide des priorités 1>2
    sched2.sched_priority = 2;
    seraient peut-être mieux placées à la suite de toutes les initialiastions
    Si tu fais des initialisations suivant ces deux déclarations de priorités, sched_priority est initialisé peut-être à zéro

  5. #5
    Membre très actif
    Homme Profil pro
    Inscrit en
    Août 2013
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Août 2013
    Messages : 274
    Par défaut
    Merci beaucoup pour vos réponses.

    Il y a quelques petites choses que je n'ai pas compris.

    Actuellement sur mon OS linux j'ai plusieurs processus en cours. A ce que j'ai compris en vous lisant, il y a un certain nombre limité de thread possible, cela est du uniquement à la capacité de la RAM qui ne peut pas contenir une infinité de programme ou il y a autre chose ?

    Ensuite j'ai l'impression de comprendre qu'il n' y a que 2 threads qui peuvent tourner sur un processeur (je possede 4 cores) donc je ne peux avoir que 8 threads sur mon ordinateur qui tournent en meme temps, or j'ai une dizaine de processus actifs (certains thread sont en pauses), j'ai donc du mal comprendre car je dépasse les 8 threads.

    Si je met plus de 2 threads par core, alors je peux gérer les priorités sur un core. Donc si je met 8 thread sur mon ordinateur, je peux gérer la priorité de mon couple de thread par core, c'est bien ca ?

  6. #6
    Membre Expert
    Inscrit en
    Mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 1 431
    Par défaut
    Tu sembles penser que les unités de traitement de ton CPU sont chacunes dédiées à un processus ou à un thread donné : ce n'est pas le cas. Les séquences d'exécution et leurs contextes sont régulièrement pré-emptées selon la stratégie adoptée par l'ordonnanceur (scheduler) du système, des centaines ou milliers de fois par seconde, et ceci afin de simuler l'exécution parallèle de tous les processus actifs du système. Ce ballet incessant est d'autant plus complexe et imprévisible que l'on s'éloigne de la stratégie d'un ordonnanceur dit temps réel.

    Attention, pour clarifier : ce que l'on (ici dalfab) appelle thread processeur, c'est de la terminologie Intel. C'est la capacité d'un seul coeur physique à effectuer certaines séquences d'opérations en parallèle, mais ce n'est pas aussi efficace qu'autant de coeurs physiques réels. Ce terme a peu de rapport avec ce que l'on nomme thread (ou parfois processus léger) au niveau du système d'exploitation.

  7. #7
    Expert confirmé
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Décembre 2015
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    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 599
    Par défaut
    C'est la mémoire disponible qui limite le nombre maximum de threads.

    Un processeur de 4 coeurs bi-threads peut avoir au maximum 8 threads dans l'état "running", mais il peut avoir un nombre quelconque de threads "ready", et des tas de threads "waiting".
    Un thread ready est un thread qui n'est pas bloqué (attente d'une ressource ou d'un timeout), il est donc en train de s'exécuter. Mais physiquement les coeurs sont limités, donc tous les threads ready se partagent le CPU.

    Exemple : 400 threads dont 380 bloqués, il reste 20 threads ready. A chaque instant le noyau en a choisi 8 "running" qui s'exécutent effectivement, les 12 autres ont été figés. Ceci n'est pas permanent, à un instant le noyau va changer d'avis (un bloqué se débloque, un running se bloque, un nouveau thread démarre, un thread meurt, un thread change de priorité ou un simple délai appelé time-slice), le noyau va alors réélire dans sa liste des ready, les 8 favoris. Cette élection parmi les "ready " des "running" se base sur des critères :
    * les plus prioritaires sont normalement préférés
    * entre 2 threads de même priorité, on préfère un ready à un running (mode round-robbin, pour un partage "juste")
    * entre 2 threads de même priorité, on préfère garder ceux déjà running (sans round-robbin, préféré par les noyau temps-réel, plus "injuste" mais plus optimal)
    * on préfère les applications foreground aux applications background (sur les systèmes multi-tâches tel que Linux)
    * un thread ayant utilisé beaucoup de CPU peut être relégué malgré sa priorité (CPU partitionning tel qu'utilisé par QNX, permet de se protéger du deni de service)
    * des threads peuvent être "boostés" en priorité temporaire par un mécanisme appelé inversion de priorité quand ils sont cause d'un blocage d'un thread très prioritaire.

    Si à un moment, il y a moins de 4 ready, c'est la tâche idle qui utilise les coeurs libres. Ça arrive très souvent.

    A ceci s'ajoute les interruptions, qui elles vont s'exécuter sur un coeur, prenant le CPU d'un thread running. Elles sont arbitrés différemment, la seule chose qui peut figer une interruption c'est que 4 interruptions plus prioritaires soient présentes.
    Une interruption quelle que soit sa priorité ne sera jamais en concurrence avec un thread quelle que soit sa priorité, l'interruption prend le CPU jusqu'à sa terminaison, le thread pré-empté doit attendre.

  8. #8
    Membre très actif
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    Mai 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Mai 2010
    Messages : 548
    Par défaut
    Bonjour,

    Vous n’êtes pas si éloigné de la solution à en lire votre code source ce qui vous manque est la définition des priorités plus exactement la valeur des priorités de vos threads avec une priorité "un" et l’autre de "deux" tous deux avec une politique d’ordonnancement RR, il est bien évident que les deux threads ne sont pas prioritaires quand ils sont dans le fil que gère l’ordonnanceur. Si j’étais vous, j’augmenterais la priorité au maximum pour l’un et pour l’autre, j’attribuerais le minimum. Éventuellement pour allée droit au but pourquoi ne pas basculer pour un thread en ordonnancement temps réel dans ce cas le thread n’est pas préémtible. L’autre thread sera alors défini en temps partagé et dans ce cas, il est préemptible et s’exécute avec une tranche de temps qui est définie par un quantum de temps, mais dans tous les cas, les threads non préemtible auront toujours la priorité et l’ordonnanceur leur attribuera cette priorité exemple:
    Code C : 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
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    224
     
    /*
     *  SAMBIA39
     *  Exemple de code source attention il
     *  Est susceptible de comporter des erreurs
     */
    #define NTHREAD     2
    #define DEF_FIFO    99
    #define DEF_OTHER   0
     
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <pthread.h>
    #include <unistd.h>
     
     
    /*
     *  Détermination des fonctionnalités POSIX
     *  pour bascule en mode temps réel le cas échéant
     *  adapter le code aux gentillesses.
     */
    #ifdef _POSIX_PRIORITY_SCHEDULING
        #include <sched.h>
    #else
        #warning "!!! Attention le mode temps réel ne peut être définis."
    #endif
     
     
    /*
     *  Fonction utilisée par les threads
     *  temps réel
     */
    void *f_thread( void *p ){
     
        size_t i = 1000;
        size_t const id = (size_t)p;
     
        (void)fprintf(stderr,
            "Thread(%zu)\t START\n", id);
     
        for( ; 0 != i; --i )
            ;
     
        (void)fprintf(stderr,
            "Thread(%zu)\t OFF\n", id);
        return NULL;
    }
     
     
    /*
     *  Fonction principale
     */
    int main( void ){
     
        int i = 0;
        extern int errno;
        pthread_t tThread[NTHREAD];
        pthread_attr_t attr_thread[2];
        struct sched_param thread_param[2];
     
        /*
         *  Acquisition des priorités max définis par le système
         *  pour les attribuer aux différends thread attention le
         *  noyau pourrais attribuer la valeur statique ou dynamique
         *  par défaut du processus en cours tout dépend du noyau à
         *  vérifier avants ou solution optimale définir soit même les
         *  priorités.
         * => Dé-commneter et commenter la partie des définitions
         *    fixées des priorités pour utiliser les priorités définies
         *    par le système
         
        const int PRIORITER_SYS_FIFO = sched_get_priority_max(SCHED_FIFO);
        const int PRIORITER_SYS_OTHER = sched_get_priority_min(SCHED_OTHER);
         
        (void)fprintf(stderr, "FIFO\t:%d\n", PRIORITER_SYS_FIFO );
        (void)fprintf(stderr, "OTHER\t:%d\n", PRIORITER_SYS_OTHER );
         */
     
    /*
     *  Ordonnancement temps réel
     */
    #ifdef _POSIX_PRIORITY_SCHEDULING
     
        errno = 0;
     
        /*
         *  Initialisation des valeurs par
         *  défaut des attributs des threads
         */
        pthread_attr_init(&attr_thread[0]);
        pthread_attr_init(&attr_thread[1]);
     
        /*
         *  Définition des priorités des thread
         *  avec les valeurs propre définis par le système.
         *  pour tester ne pas mettre sous commentaire
         *
        thread_param[0].sched_priority = PRIORITER_SYS_OTHER;
        thread_param[1].sched_priority = PRIORITER_SYS_FIFO;
         */
     
        /*
         *  Définition volontaire des priorités
         *  indépendamment de celui du noyau
         *  /!\Attention valeur max FIFO est de 99.
         */
         thread_param[0].sched_priority = DEF_OTHER;    // thread un en OTHER
         thread_param[1].sched_priority = DEF_FIFO;   // thread deux en FIFO
     
        /*
         *  Définition du type d'ordonnancement
         *  aux attributs des différents threads
         *  avec les paramètre indiquer.
         *  paramètre OTHER = temps partager (defaut)
         *  paramètre FIFO = temps réel.
         */
        if( 0 !=
           (errno = pthread_attr_setschedpolicy(&attr_thread[0],
             SCHED_FIFO)) && ( 0 !=
            (errno = pthread_attr_setschedpolicy(&attr_thread[1],
            SCHED_RR)))){
     
            // Destruction des attributs
            (void)pthread_attr_destroy(&attr_thread[0]);
            (void)pthread_attr_destroy(&attr_thread[1]);
     
            (void)fprintf(stderr,
                "Erreur(%d)\t:%s\n\t:%s",errno,
                "Erreur setschedpolicy", strerror(errno) );
            return EXIT_FAILURE;
        }
     
        // Suite definition des ordonnancement.
        if( 0 !=
           (errno = pthread_attr_setinheritsched(&attr_thread[0],
                PTHREAD_EXPLICIT_SCHED))&& (0 !=
                (errno = pthread_attr_setinheritsched(&attr_thread[1],
                PTHREAD_EXPLICIT_SCHED)))){
     
            // Destruction des attributs
            (void)pthread_attr_destroy(&attr_thread[0]);
            (void)pthread_attr_destroy(&attr_thread[1]);
     
            (void)fprintf(stderr,
                "Erreur(%d)\t:%s\n\t:%s",errno,
                "Erreur setinheritsched", strerror(errno) );
            return EXIT_FAILURE;
        }
     
     
        /*
         *  Définition individuels des threads
         *  et de façon distincte l'un OTHER et
         *  l'autre FIFO
         */
     
        if( 0 !=
           (errno = pthread_attr_setschedparam(&attr_thread[0],
                    &thread_param[0])) && (0 !=
            (errno = pthread_attr_setschedparam(&attr_thread[1],
                    &thread_param[1])))){
     
            (void)fprintf(stderr, "Erreur(%d)\t:%s\n\t:%s",errno,
                          "Erreur pthread_attr_setschedparam",
                          strerror(errno) );
            return EXIT_FAILURE;
        }
     
        /*
         *  Création thread un
         */
        if( 0 != (errno = pthread_create(&tThread[0],
            &attr_thread[0], f_thread, (void*)(1)))){
     
            (void)fprintf(stderr,
                "Erreur(%d)\t:%s[%d]\n\t:%s",errno,
                "Erreur pthread_create", i,
                strerror(errno) );
            return EXIT_FAILURE;
        }
     
        /*
         *  Création thread deux
         */
        if( 0 != (errno = pthread_create(&tThread[1],
            &attr_thread[1], f_thread, (void*)(2)))){
     
            (void)fprintf(stderr,
                "Erreur(%d)\t:%s[%d]\n\t:%s",errno,
                "Erreur pthread_create", i,
                strerror(errno) );
            return EXIT_FAILURE;
        }
     
        /*
         *  Attente de la fin des threads et
         *  code retour des threads est volontairement
         *  ignorée.
         */
        for( i = 0; i < NTHREAD; i++ )
            (void)pthread_join(tThread[i], NULL );
     
        /*
         *  Destruction des attributs.
         *  des deux threads
         */
        (void)pthread_attr_destroy(&attr_thread[0]);
        (void)pthread_attr_destroy(&attr_thread[1]);
        return EXIT_SUCCESS;
     
     
    #else
        /*
         *  Cas contraire on opte pour nice par exemple
         *  en fixant la gentillesse avec soit la commande depuis le terminal
         *  nice -n valeur_increment ./app argument
         *  ou par la fonction nice.
         */
        return EXIT_SUCCESS;
    #endif
     
        return EXIT_SUCCESS; // Jamais atteinte.
    }

    Citation Envoyé par dalfab Voir le message
    Bonjour,

    La priorité ne sert pas à dire qui sera fait en premier.
    Déjà son sens dépend si le logiciel est exécuté dans un système Temps-réel (qui doit garantir des temps de réactions) ou MultiThread (comme Windows ou Unix qui doit garantir qu'un thread même très prioritaire ne bloque pas le système). Ensuite il dépend aussi du type de partage (round-robin, Highest, CPU quantum, ...). Et le comportement est aussi lié au nombre de threads du processeur.
    La priorité n'a de sens qu'au moment où il y a conflit d'accès au CPU.
    Si les threads sont simultanément dans l'état "Ready" ET qu'il n'y pas assez de Thread processeur disponibles, alors la priorité va arbitrer lequel prend le CPU (et dans certains cas, le moins prioritaire peut être choisi!)
    Si 2 threads appellent une fonction système tout est possible (et ici tu appelles printf()), le noyau va donner une "préférence" au plus prioritaire au moment des conflits, mais le moins prioritaire peut tout à fait se terminer avant le plus prioritaire.
    Par être sûr qu'un thread exécute un code après un autre, il faut utiliser des synchronismes (rendez-vous, sémaphore, condition variable, ...)
    Je ne suis pas tout à fait d’accord avec cette réponse et ceux pour les raisons suivantes:
    Quel que soit le type de processus (voir thread) ils possèdent tous sans exception une priorité et sont insérée dans la fil associe à leur type tel est le cas du noyau Linux:
    • SCHED_FIFO pour les processus ou thread temps réel donc ils sont non préemptibles.
    • SCHED_RR pour les processus ou thread temps réel préemtible.
    • SCHED_OTHERD pour les processus normaux dits ordinaires ils sont donc non temps réel.

    Le noyau Linux a donc trois politiques d’ordonnancement pour gérer les ressources et ses priorités jouent un rôle.
    Les processus ou thread temps réel dit SCHED_FIFO sont prioritaires devant les processus ou thread SCHED_RR qui sont eux-mêmes prioritaires devant les processus ou threads SCHED_OTHERD. L’ordonnanceur choisira toujours le processus ou thread prioritaire.
    Exemple: Quand vous avez un processus ou thread du type SCHED_FIFO qui est dans le fil associer au processus SCHED_FIFO, l’ordonnanceur va alors exécuter ce processus à la place du processus courant, (c’est-à-dire le processus qui était en cours d’exécution) et c’est lui qui pourra abandonner le processeur en invoquant sched_yield(); et alors le processus courant suspendu précédemment va prendre le CPU à la place du processus prioritaire qui a libéré le CPU.
    Pour ce qui est de la file SCHED_RR, ils sont gérés en tourniquet, c'est-à-dire avec une seule file d’attente et exécutés pour la durée d’un quantum de temps à l’issue de ce délai de temps s’il y a un processus prioritaire parmi les processus ou thread de type SCHED_FIFO sera choisi même s'il y a un processus ou thread SCHED_RR dans le cas où il n’y a plus de processus ou thread SCHED_FIFO dans une file alors les où le processus de priorité SCHED_RR sera alors élu le plus souvent le processus le plus prioritaire des SCHED_RR qui sera élu devant ceux qui sont le moins prioritaire. Les processus SCHED_OTHER sont également exécutés et en mode tourniquet, mais il sera exécuté uniquement quand la file SCHED_FIFO et SCHED_RR seront vides et l’insertion des threads SCHED_OTHER se font en fonction des priorités. Dans le cas où ils existent tous deux des processus SCHED_OTHER alors, l’insertion dans le fil sera en mode FIFO.

    Aux finales, l’ordonnanceur prend bien compte des priorités et admet toujours pour le CPU les processus les plus prioritaires. Techniquement les priorités sont calculées à partir d’un segment du code modifiable par l’utilisateur à travers la fonction nice ou setpriority, mais l’utilisateur ne pourra pas diminuer la priorité de son processus; il ne pourra que l’augmenter; bien entendu sous couverts qu’il soit root. La priorité est également calculée en fonction de la partie dite système qui baisse lorsque le processus consomme un certain nombre de cycles d’horloge pour permettre à d'autres processus moins prioritaires de s’exécuter rapidement. Tous ces facteurs rentrent en compte, mais le processus le plus prioritaire d’une file sera exécuté en premier.

    Dans le cas du système Unix, c’est différent, car elle est basée sur une politique de priorité qui est une priorité interne définie par l’ordonnanceur ou priorité dite externe fixée par le développeur donc il peut y a avoir qu’une seule file d’attente unique où les processus vont être ordonnés suivant leur priorité; ou plusieurs files ordonnées selon leur priorité de manière à satisfaire une autre file quand la file de plus haute priorité est vide.
    Unix peut également utiliser l’ordonnancement temps réel et pourrait appliquer divers algorithmes comme: Deadline Monotonic et Rate Monotonic pour des priorité fixe. Earliest Deadline et Least Laxity pour les priorité dynamique. .

    Sous le système Windows tous, les processus ou thread n’ont pas la même importance et donc il utilise un ordonnancement avec priorité comme Unix, l’ordonnancer lancera alors le processus qui a la plus grande priorité. les priorités sont donc prises en compte par l’ordonnanceur et l’ordonnanceur attribueront les accès CPU en fonction de la file et des priorités entre processus selon la politique de la file.

    Autres points que je n’ai pas évoqués qui me semble important. Il faut différencier les threads des processus tous comme ce qui est vraiment un système temps réel d’un système à temps partagé. Pour faire simple, les threads sont des unités d’exécution rattachée à un processus, chargée d’excuser une partie du processus parallèlement à d’autres qui sont en cours d’exécution et qui partagent le même espace d’adressage.
    Le processus quant à lui (pour faire simple) est vu comme étant un ensemble de ressources que ces threads partagent ils s’exécutent donc dans des espaces mémoire distincts (Plus précisément dans un espace mémoire totalement indépendant et protéger des autres processus ; dans une mémoire virtuelle qui lui est allouée, un processus a la possibilité d’exécuter un ou de nombreux threads).
    Chaque thread possède également sa propre pile, un contexte d’exécution qui contient les registres du processus et un compteur d’instructions.
    Aux finales, les threads sont des tâches indépendantes partageant les mêmes ressources dynamique et statique. Et les processus peuvent être vus comme une sorte paquet qui regroupe les ressources. (l’architecture également rentre en compte tout comme le nombre de threads par système. Exemple Linux est limité par un nombre maximum de processus que l’on peut créer sur le système et ce nombre dépendant du système.)

    Attention tout de même, il y a un distinguo à faire entre les threads, c’est-à-dire qu’il ne faut surtout pas confondre les threads dits applicatifs implémentés grâce à un support noyau des threads noyau qui sont des portions de code exécutées dans l’espace mémoire du noyau avec les privilèges hérités de ce dernier tout en étant ordonnancé par l’ordonnanceur..

    autre remarque pour finir, les systèmes d’exploitation Linux du grand public sont limités. Attention quand je dit limité je parle de la partie des temps réels car elle est liée à la gestion des interruptions par le noyau qui sont des actions lourdes réaliser au détriment de l’espace dite applicatif et si l’on désire outrepasser ses limites il va falloir songer à opter pour des systèmes temps réel strict comme RTAI, Xenomai, QNX, etc. qui retarde le traitement non-urgent des interruptions pour laisser les tâches de haute priorité s’exécuter en premier.

    à bientôt

  9. #9
    Membre Expert

    Homme Profil pro
    Responsable des études
    Inscrit en
    Mars 2009
    Messages
    553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2009
    Messages : 553
    Par défaut
    En fait, dans l'exemple donné, changer la priorité des threads n'a pratiquement aucun intérêt. À cause de "printf".

  10. #10
    Membre très actif
    Homme Profil pro
    Inscrit en
    Août 2013
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Août 2013
    Messages : 274
    Par défaut
    pourquoi quel est le probleme avec printf ?

Discussions similaires

  1. [XL-2010] Comment gérer les priorités de mise en forme conditionnelle dans un programme VBA
    Par Alain777 dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 16/04/2015, 22h26
  2. [Google Maps] (API V3) Comment gérer les priorités d'Overlays ?
    Par Kentin64 dans le forum APIs Google
    Réponses: 3
    Dernier message: 09/08/2011, 09h02
  3. Comment créer un thread qui puisse gérer les éléments de l'IHM
    Par SuperSeb95 dans le forum Multithreading
    Réponses: 14
    Dernier message: 18/05/2011, 11h43
  4. [Pascal / SDL] Problème pour gérer les Threads…
    Par Sn00ze92 dans le forum Langage
    Réponses: 2
    Dernier message: 24/02/2009, 17h40
  5. gérer les threads
    Par youp_db dans le forum Concurrence et multi-thread
    Réponses: 5
    Dernier message: 08/01/2006, 16h42

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