65
Systèmes & Systèmes & Programmations Temps Programmations Temps Réelle Réelle Master MSRS [email protected] 1

Systèmes & Programmations Temps Réelle

  • Upload
    marcie

  • View
    39

  • Download
    1

Embed Size (px)

DESCRIPTION

Systèmes & Programmations Temps Réelle. Master MSRS [email protected]. Programmations temps Réelle. Problématique des RTOS Quelqu'un pose des questions concernant la température extérieure actuelle. Laquelle est la meilleure réponse ? - PowerPoint PPT Presentation

Citation preview

Page 1: Systèmes & Programmations Temps Réelle

Systèmes & Programmations Systèmes & Programmations Temps RéelleTemps Réelle

Master [email protected]

1

Page 2: Systèmes & Programmations Temps Réelle

Programmations temps Réelle

Problématique des RTOSQuelqu'un pose des questions concernant la température extérieure actuelle. Laquelle est la meilleure réponse ?

• Une réponse correcte de 20 ° C mais livré 12 heures plus tard; • ou Une lecture erronée de 10 ° C livré immédiatement;

Dans un système temps réel, une réponse tardive est tout aussi mauvais qu'une réponse fausse

ObjectifsDans ce cours, nous allons introduire des méthodes et des modèles pour contrôler le comportement temporel des programmes, en outre leur fonctionnalité

2

Page 3: Systèmes & Programmations Temps Réelle

Définition

• Les systèmes informatiques temps réel se différencient des autres systèmes informatiques par la prise en compte de contraintes temporelles dont le respect est aussi important que l'exactitude du résultat

système TR ne doit pas simplement délivrer des résultats exacts, il doit les délivrer dans des délais imposés.

3

Page 4: Systèmes & Programmations Temps Réelle

4

Page 5: Systèmes & Programmations Temps Réelle

Domaine d'utilisation

• Les systèmes informatiques temps réel sont aujourd'hui présents dans de nombreux secteurs d'activités 

• Industrie de production par exemple, au travers des systèmes de contrôle de procédé (usines, centrales nucléaires),

• Marché Boursier au travers du traitement des données boursières en « temps réel »

• Aéronautique au travers des systèmes de pilotage embarqués (avions, satellites),

• Médecine -- Robots

5

Page 6: Systèmes & Programmations Temps Réelle

RTOS

• Le développement de systèmes temps réel nécessite donc que chacun des éléments du système soit lui-même temps réel (prendre en compte des contraintes temporelles)

• système d'exploitation conçu pour prendre en compte ces contraintes est appelé système d'exploitation temps réel « RTOS »

6

Page 7: Systèmes & Programmations Temps Réelle

Exemple : Impact du temps réel sur les systèmes

7

Le but de l'expérience est de générer un signal périodique sortant du port parallèle du PC.

•Le temps qui sépare deux émissions du signal sera mesuré à l'aide d'un compteur. •Le but est de visualiser l'évolution de ce délai en fonction de la charge du système. • La fréquence initiale du signal est de 25 Hz (Hertz) ce qui donne une demi-période T/2 de 20 ms.

Page 8: Systèmes & Programmations Temps Réelle

8

Sur un système classique, cette demi-période varie de 17 à 23 ms, ce qui donne une variation de fréquence entre 22 Hz et 29 Hz. La figure ci-dessous donne la représentation graphique de la mesure sur un système non chargé puis à pleine charge

Page 9: Systèmes & Programmations Temps Réelle

9

Sur un système temps réel, la demi-période varie entre 19,990 ms et 20,015 ms, ce qui donne une variation de fréquence de 24,98 Hz à 25,01 Hz. La variation est donc beaucoup plus faible. La figure donne la représentation graphique de la mesureLorsque la charge est maximale, le système temps réel assure donc une variation de +/- 0,2 Hz alors que la variation est de +/- 4 Hz dans le cas d'un système classique.

Page 10: Systèmes & Programmations Temps Réelle

10

CPU sans Charge

On remarque que l'on n'a pas une période de 100 ms mais de 119,6 ms dû au temps supplémentaire d'exécution des appels système.

CPU avec Charge

On stresse le système (écriture répétitive sur disque d'un fichier de 50 Mo), on observe Effet de Jitter(gigue). La gigue maximale sur la durée de l'expérience est de 17,6 ms. La forme du signal varie maintenant au cours du temps, n'est pas de forme carrée mais rectangulaire. LINUX n'est donc plus capable de générer correctement ce signal

Page 11: Systèmes & Programmations Temps Réelle

Rappel OS

11

Page 12: Systèmes & Programmations Temps Réelle

• Système d'exploitation se présente donc comme une couche logicielle placée entre la machine matérielle et les applications

• OS s'interface avec la couche matérielle, notamment par le biais du mécanisme des interruptions

• OS peut être découpé en plusieurs grandes fonctions

12

Page 13: Systèmes & Programmations Temps Réelle

• Gestion du processeur – algorithme d'ordonnancement qui planifie l'exécution

des programmes.• Gestion de la mémoire

– Allocation de mémoire• Gestion des entrées/sorties• Gestion de la concurrence

– synchroniser l'accès aux données partagées afin de maintenir leur cohérence

• Gestion des objets externes– Système de gestion de fichiers (SGF)

• Gestion de la protection

13

Page 14: Systèmes & Programmations Temps Réelle

RTOS

14

Page 15: Systèmes & Programmations Temps Réelle

RTOS1- Task management and scheduling

– Gestionnaire des Taches est la tâche principale du système d'exploitation

• les tâches doivent être créés et supprimés alors que le système est en cours d'exécution;

• les tâches peuvent modifier leurs niveaux de priorité, leurs contraintes de temps, leurs besoins en mémoire; etc

15

Page 16: Systèmes & Programmations Temps Réelle

RTOS Gestion des tâche est plus dangereuse Gestion des tâche est plus dangereuse que pour un usage général OSque pour un usage général OSExemple : Si une tâche temps réel est créée, il doit

obtenir la mémoire dont il a besoin sans délai, et que la mémoire doit être verrouillée pour éviter:

1. les temps d'accès en raison de permutation,2. l'évolution des priorités d'exécution influe sur le

comportement à l'exécution de l'ensemble du système

la prévisibilité qui est très important la prévisibilité qui est très important pour RTOSpour RTOS

16

Page 17: Systèmes & Programmations Temps Réelle

2- Services des Interruptions

• Un système d'exploitation ne doit pas seulement être en mesure de planifier des tâches selon un algorithme déterministe, mais elle a aussi la tache de servir le matériel périphérique via interruption

17

Page 18: Systèmes & Programmations Temps Réelle

3- Communication & synchronisation

• IPC (Inter-Process Communication )recueille un grand nombre de primitives de programmation que l’OS met à la disposition des tâches qui ont besoin d'échanger des informations avec d'autres tâches, ou de synchroniser leurs actions;

• RTOS doit s'assurer que cette communication et la synchronisation se déroulent de manière déterministe;

• Cette communication peut être effectuer avec d'autres ordinateurs, ou avec le matériel périphérique.

18

Page 19: Systèmes & Programmations Temps Réelle

4 -Gestion mémoire

• Donner à chacun la tâche de la mémoire dont il a besoin (allocation de mémoire)

• Prendre les « mesures appropriées » lorsqu'une tâche utilise la mémoire qu’elle ne lui a pas été attribué. – Exemple : pointeurs non connecté et d'indexation de

tableau au-delà des limites du tableau"mesures appropriées« : dépend de l'application, souvent

cela se résume à la solution la plus simple: tuer la tâche et avertir l'utilisateur

19

Page 20: Systèmes & Programmations Temps Réelle

Trade-offs (compromis)

20

noyau monolithiquenoyau monolithiquemicro-noyaumicro-noyau

Espace noyau vis-à-vis espace utilisateurEspace noyau vis-à-vis espace utilisateur

Page 21: Systèmes & Programmations Temps Réelle

• Un noyau monolithique possède tous les services de l'OS (y compris les pilotes de périphérique, piles de réseau, les systèmes de fichiers, etc) en cours d'exécution en mode privilégié du processeur.

• Un micro-noyau, d'autre part, utilise le mode privilégié uniquement pour les services vraiment de base (gestion des tâches et ordonnancement, communication inter-processus, la gestion des interruptions, et de la mémoire gestion), et possède la plupart des pilotes de périphériques et de services de l'OS en tant que des tâches «normales»

21

Page 22: Systèmes & Programmations Temps Réelle

Noyau préemptif ou non

• Linux a été initialement un noyau non-préemptif– une tâche "espace noyau" ne peut pas être interrompu ne peut pas être interrompu par d'autres tâches de

"l'espace noyau", ou par des tâches de « l'espace utilisateur »

22

•Le noyau est "verrouillé " tant qu’il est en exécution. •Utilisation de serrures permet la conception de la plus simple du noyauInconvénient : il introduit des latences déterministes latences déterministes qui ne sont pas tolérables dans un RTOS.

Page 23: Systèmes & Programmations Temps Réelle

Contrainte de temps

• " Un système d'exploitation temps réel est capable d'exécuter toutes ses Un système d'exploitation temps réel est capable d'exécuter toutes ses tâches sans tâches sans violer les contraintes de temps violer les contraintes de temps spécifié spécifié «

• « Temps au cours de laquelle les tâches exécutera peut être « Temps au cours de laquelle les tâches exécutera peut être prédit de façon prédit de façon déterministe déterministe sur la base des connaissances sur le coté matériel et logiciel du sur la base des connaissances sur le coté matériel et logiciel du systèmesystème «

• On distingue le temps réel strict strict ou durdur (de l'anglais hard real-time) et le temps réel souplesouple ou moumou (soft real-time) suivant l'importance accordée aux contraintes temporelles.

• Le temps réel strict ne tolère aucun dépassement de ces contraintes, – tels dépassements peuvent conduire à des situations critiques, voire

catastrophiques :• Exemple : pilote automatique d'avion, système de surveillance de centrale nucléaire, etc.

• À l'inverse le temps réel souple s'accommode de dépassements des contraintes temporelles dans certaines limites au-delà desquelles le système devient inutilisable : visioconférence, jeux en réseau, etc.

23

Page 24: Systèmes & Programmations Temps Réelle

Le temps de latence • Le temps de latence (ou retard) d'une tâche = différence

entre l'instant de temps sur laquelle la tâche doit commencer (ou terminer) et l'instant à laquelle il est effectivement en exécution – le temps écoulé entre la génération d'un événement, et sa

perception

24

r : date de réveil c'est le moment du déclenchement de la 1ere requête d'exécutionC : durée d'exécution maximale (capacité)D : délai critique c'est le délai maximum acceptable pour son exécutionP : période si la tâche est périodique

Page 25: Systèmes & Programmations Temps Réelle

Le temps de latenceLe temps de latence est du à plusieurs facteurs: (i) les propriétés de synchronisation du processeur, bus, la mémoire

(mémoire cache, RAM hors puce et ROM) et périphérique dispositifs;(ii) les propriétés de la programmation du système d'exploitation;(iii) le caractère préemptif ou non du noyau;(iv) la charge sur le système ( le nombre de tâches qui veulent être

programmées en même temps);(v) le temps du au changement de contexte. Ce dernier est le temps

nécessaire que le processeur a besoin pour sauvegarder les données de la tâche en cours d'exécution (par exemple, les registres, la pile et pointeur d'instruction), et de le remplacer par les données locales de la tâche nouvellement prévue.

Conséquence:Conséquence:– Ces facteurs ne sont pas constants au fil du temps et introduisent

l'indéterminisme dans le comportement temporel du système

25

Page 26: Systèmes & Programmations Temps Réelle

Ordonnancement temps-réel

Problème– Calculs à exécuter + contraintes de temps = dans quel

ordre exécuter ?DéfinitionDéfinition

Ensemble des règles définissant l’ordre d’exécution des calculs sur le processeur

Pourquoi ordonnancerPourquoi ordonnancer ?Parce que ça a un impact sur le respect des contraintes

de tempsExemple• Tâche T1 : arrivée en r=0, durée C=4, échéance D=7• Tâche T2 : arrivée en r=2, durée C=2, échéance D=5• Ordonnancement O1Ordonnancement O1: premier arrivé, premier servi,

on n’interrompt jamais une tâche• Ordonnancement O2Ordonnancement O2: priorité, T2 plus prioritaire

que T126

Page 27: Systèmes & Programmations Temps Réelle

C’est quoi une Thread?

27

•Une thread peut être vue comme étant la plus petite unité d'exécution. •Chaque thread a :

• sa pile, •son pointeur de programme • ses registres.

•Processus définit le contextecontexte dans lequel les threads s'exécuteront.

Le contexte contient les threads, le code exécutable, les données, les descripteurs de fichiers, les outils de synchronisation, etc.

Processus = = conteneur de threads(processus est décomposé en tâches ).•tâche est une sorte de processus léger plus ou moins indépendamment des autres

Page 28: Systèmes & Programmations Temps Réelle

28

Page 29: Systèmes & Programmations Temps Réelle

Classification des ordonnancements

• Instant ou l’ordre d’exécution est décidé : hors-ligne /en-ligne

• Possibilité d’interruption d’une tâche par une autre: préemptif / non préemptif

• Optimalité : quel est le « meilleur » ordonnancement

29

Page 30: Systèmes & Programmations Temps Réelle

Buts de l'ordonnancement

Piloter l'application avec 2 objectifs majeurs :➢ en fonctionnement nominal : respect des contraintesrespect des contraintes

temporellestemporelles➢ en fonctionnement anormal (par exemple pannes

matérielles) : atténuer les effets des surcharges atténuer les effets des surcharges et maintenir un état cohérent et sécuritaire

ordonnancer = planifier l'exécution des requêtes de façon à respecter les contraintes de temps

➢ de toutes les requêtes en fonctionnement nominal➢ d'au moins les requêtes les plus importantes (c'est-a-dire

celles nécessaires a la sécurité du procède) en fonctionnement anormal

(RT dure)

30

Page 31: Systèmes & Programmations Temps Réelle

Ordonnancement « hors-ligne » / « enligne"

Ordonnancements "en-ligne "– Les décisions d’ordonnancement sont prise au

cours de l’exécution– A l’exécution, l’ordonnanceur implante un

algorithme d’ordonnancement permettant de savoir à tout instant quel tâche exécuter : besoin d’un exécutif multitâche

– Généralement, ordonnancements conduits par la priorité

31

Page 32: Systèmes & Programmations Temps Réelle

Ordonnancement non préemptif / préeemptif

• Non préemptif: On n’interrompt jamais l’exécution d’une tâche en cours au profit d’une autre tâche

• Préemptif: La tâche en cours peut perdre involontairement le processeur au profit d’une autre tâche (jugée plus urgente)

Remarques : orthogonal par rapport à la classification en-ligne / hors-ligne

32

Page 33: Systèmes & Programmations Temps Réelle

Exemple d’ordonnancement préemptif : conduit par la priorité

33

• Algorithme d’ordonnancement : sélectionner la tâche la plus prioritaire• priorité(T3) > priorité(T2) > priorité(T1) (ici, priorités fixes)T1, T2 et T3 arrivent respectivement aux dates 1, 2,et 3

Page 34: Systèmes & Programmations Temps Réelle

Caractéristiques des tâches

• r : date de réveil c'est le moment du déclenchement de la 1ere requête d'exécution

• C : durée d'exécution maximale (capacité)• D : délai critique c'est le délai maximum acceptable pour son exécution• P : période si la tâche est périodique• d = r+D : échéance (si tâche a contraintes strictes)

• Pour les tâches périodiques : rk = r0 + k*P

– Si D = P, tâche est une tâche à échéance sur requête

34

Page 35: Systèmes & Programmations Temps Réelle

paramètres statiquesparamètres statiques ➢ Ui = Ci/Pi : facteur d'utilisation du processeur c-à-d pourcentage de l’activité du processeur dédiée à la tâche Ti

➢ CH = C/D : facteur de charge du processeurparamètres dynamiquesparamètres dynamiques

➢ s : date du début de l'exécution ➢ e : date de la fin de l'exécution ➢ D(t) = d-t : délai critique résiduel a la date t (0 ≤ D(t) ≤ D) ➢ C(t) : durée d'exécution résiduelle a la date t (0 ≤ C(t) ≤ C) ➢ L = D-C : laxité nominale de la tâche

• ✔ Retard maximum pour son début d'exécution s (si elle est seule)

• ➢ L(t) = D(t) - C(t) : laxité nominale résiduelle• ✔ Retard maximum pour reprendre l'exécution• ➢ TR = e - r : temps de réponse de la tâche• ➢ CH(t) = C(t)/D(t) : charge résiduelle (0 ≤ CH(t) ≤ C/P)

35

Page 36: Systèmes & Programmations Temps Réelle

Etat d'une tâche

Les diverses états d’une tâche:– Prêtes (ready) : la tâche n'a pas encore commencé à s'exécuter ou à

être interrompue par préemption– en cours d'exécution (running) : la tâche est en cours d'exécution et

utilise le processeur– bloquées (blocked) : de manière générale, la tâche est en attente de

la ressource– endormie (sleeping) : la tâche n'est pas encore terminée et est en

attente d'un réveil.

36

Page 37: Systèmes & Programmations Temps Réelle

Définition

configuration : ensemble de n taches mises en jeu par l'application➢ Facteur d'utilisation du processeur ➢ Facteur de chargePour tout système de n tâches, la condition suivante est nécessaire mais pas

suffisante à sa faisabilité :U<1

Avec Ci le temps de calcul de la tâche n° i et Pi sa période. Une valeur supérieure à 1 signifierait que le système nécessite plus de temps d'exécution que le processeur ne peut en fournir.

Intervalle d'etude Intervalle d'etude : intervalle de temps minimum pour prouver l'ordonnançabilite d'une configuration

➢ Le PPCM des périodes dans le cas d'une configuration de tâches périodiqueslaxité du processeur LP(t) laxité du processeur LP(t) = intervalle de temps pendant lequel le processeur peut

rester inactif tout en respectant les échéances• ✔ laxité conditionnelle: (somme sur les taches déclenchées a la date t et qui

sont devant i du point de vue de l'ordonnancement)• ✔ LP(t) = min(LCi(t))

37

Page 38: Systèmes & Programmations Temps Réelle

Ordonnancement des tâches independents

tâches périodiques

1. A priorités statiques

• Rate monotonic : fondé sur les périodes• Deadline monotonic : fondé sur les délais critiques

2 A priorités dynamiques

• Earliest deadline : fondé sur les échéances• Least laxity : fondé sur la marge de manœuvre restante

38

Page 39: Systèmes & Programmations Temps Réelle

Rate Monotonic Analysis (RMA)Rate Monotonic Analysis (RMA)

• Algorithme a priorité constante• Condition d’ordonnançabilité (pour Pi = Di) • se base sur la période (taches à échéance sur requête) :

la tâche de plus petite période est la plus prioritaire

• test d'acceptabilités (condition suffisante) : théoriquement, le concepteur d'un système temps réel prétendu strict devrait être capable de prouver que les limites temporelles ne seront jamais dépassées quelle que soit la situation. Cette vérification est appelée "test d'acceptabilité", "analyse de faisabilité" ou encore "contrôle d'admission.

– Elle dépend de l'ordonnanceur utilisé et des caractéristiques des tâches du système.

39

quand nn est très grand : n (2n (21/n1/n – 1) ~ ln 2 = 0,69 – 1) ~ ln 2 = 0,69

Page 40: Systèmes & Programmations Temps Réelle

Exemple :T1 (r0=0, C=3, P=20), T2 (r0=0, C=2, P=5), T3 (r0=0, C=2, P=10) ΣCi/Pi = 3/20+2/5+2/10 = 0,75 n(21/n−1) =3(21/2−1)= 0,77 Le test d'acceptabilités est validéPriorité2 > Priorité3 > Priorité1 (le classement s'effectue sur la période la plus petite)

40

Page 41: Systèmes & Programmations Temps Réelle

Deadline Monotonic Analysis (DMA)

• Algorithme a priorité constante• base sur le délai critique D:• ➢ La tâche de plus petit délai critique est la plus

prioritaire

• test d'acceptabilités (condition suffisante)

• Équivalent à RMA dans le cas des taches à échéance sur requête, meilleur dans les autres cas

41

Page 42: Systèmes & Programmations Temps Réelle

Exemple: T1(r0 = 0, C=3, D=7, P=20), T2 (r0 = 0, C=2,

D=4, P=5),T3 (r0 = 0, C=2, D=9, P=10)ΣCi/Pi= 3/7+ 2/4+ 2/9 = 1,14 ≥ n(21/n−1) = 0,77Priorité2 > Priorité1 > Priorité3 (le classement

s'effectue sur le plus petit délai critique D)

42

Page 43: Systèmes & Programmations Temps Réelle

Tâches apériodiques

Tâches apériodiques : elles correspondent aux événements; elles se réveillent de manière aléatoire.– Apériodiques strictes : contraintes temporelles

dures à respecter absolument.– Apériodiques relatives : contraintes temporelles

molles qui peuvent être ou non respectées de temps à autre (sans échéance).

43

Page 44: Systèmes & Programmations Temps Réelle

Model Tâche apériodique Stricter: date aléatoire de réveil de la tâcheC: durée d ’exécution maximaleD : délai critique dk : échéance = rk + RR(t): délai critique dynamique (temps restant à t jusqu’à d)Tap( r, C, R)Tap (t, C(t), R(t)) Diagramme temporel d ’exécution

44

Modèle canonique d'une tâche apériodique temps réel Tap (t, C(t), Dt)) C(t): temps d’exécution restant à t

Page 45: Systèmes & Programmations Temps Réelle

Traitement d'arrière-plan

• taches apériodiques ordonnancées quand le processeur est oisif

• ➢ les tâches périodiques restent les plus prioritaires

• ordonnancement relatif des taches apériodiques en mode FIFO

• traitement le plus simple, mais le moins performant

45

Page 46: Systèmes & Programmations Temps Réelle

• exemple• Tp1 (r0=0, C=2, P=5), Tp2 (r0=0, C=2, P=10)• Ta3 (r=3, C=2), Ta4 (r=10, C=1), Ta5 (r=11, C=2)• ➢ ordonnancement RMA des taches periodiques

46

Page 47: Systèmes & Programmations Temps Réelle

Serveur des Tâches apériodique

•Serveur de scrutation :• A chacun de ses réveils, le serveur sert les tâches

apériodiques en attentedepuis son réveil précédent- jusqu’à épuisement des tâches apériodiques- jusqu’à épuisement de sa capacité• L’ordre de service des tâches apériodiques est

quelconque• La capacité non utilisée est perdue

47

Page 48: Systèmes & Programmations Temps Réelle

48

Page 49: Systèmes & Programmations Temps Réelle

49

Exemple de tâche Serveur Scrutation

Page 50: Systèmes & Programmations Temps Réelle

Thread Thread POSIXPOSIX : Pthread : Pthread

Qu'est ce qu'est un thread?– Techniquement, un thread est défini comme un

flux d'instructions indépendant qui peut être programmé pour s'exécuter en tant que tels par le système d'exploitation.

Mais qu'est-ce que cela signifie?• Pour le développeur du logiciel, le concept d'une

«procédure» qui s'exécute indépendamment de son programme principal peut le mieux décrire un thread.

50

Page 51: Systèmes & Programmations Temps Réelle

AnalogiePour aller plus loin, imaginez un programme

principal (a.out) qui contient un certain nombre de procédures.

Alors imaginez toutes ces procédures pouvant être programmé pour s'exécuter simultanément et / ou de façon indépendante par le système d'exploitation.

ça serait de décrire un programme «multi-thread».

51

Page 52: Systèmes & Programmations Temps Réelle

Avant de pouvoir comprendre le fonctionnent d’un thread, il faut d'abord comprendre le fonctionnent d’un processus UNIX.

Un processus est créé par le système d'exploitation, et exigeant « Overhead » en terme d'exploitation de ressources en particulier des informations sur les ressources du programme et l'état d'exécution du programme, notamment:– Process ID, process group ID, user ID, and group ID – Registers – Stack – Heap – File descriptors – Inter-process communication tools (such as message

queues, pipes, semaphores, or shared memory)… etc.

52

Page 53: Systèmes & Programmations Temps Réelle

Threads utilisent et existent au sein même des ressources de processus;

Threads fonctionnent en grande partie comme des entités indépendantes parce qu'ils reproduire uniquement les ressources dont ils auraient besoin et qui leur permettraient d'exister en tant que code exécutable.

Thread gère ses propres ressources(indépendance) :– Stack pointer – Registers – Scheduling properties (such as policy or priority) – Set of pending and blocked signals – Thread specific data.

53

Page 54: Systèmes & Programmations Temps Réelle

54

Page 55: Systèmes & Programmations Temps Réelle

En résumé, dans l'environnement UNIX un threadEn résumé, dans l'environnement UNIX un thread:– Existe au sein d'un processus et utilise les ressources de

processus– A son propre flux de contrôle est indépendant aussi longtemps

que son processus parent existe et le système d'exploitation qu'il supporte

– Duplique seulement les ressources essentielles dont il a besoin d'être ordonnancés indépendamment

– Peuvent partager les ressources de processus avec les autres threads qui agissent aussi de façon indépendante (et dépendante)

– Détruit si le processus parent meurt - ou quelque chose de semblable

– Thread est"léger" car la plupart des coûts d'exploitation a déjà été accompli par la création de son processus.

– Comparé au coût de création et de gestion d'un processus, un thread peut être créé avec des « Overhead » du système d'exploitation beaucoup moins élevé.

55

Page 56: Systèmes & Programmations Temps Réelle

56

Page 57: Systèmes & Programmations Temps Réelle

Applications multitâches offrent des gains de performance potentiels et des avantages pratiques par rapport aux applications n'utilisant pas les threads

par exemple :• Le chevauchement de travail CPU avec les opérations d'

E/S: Par exemple, un thread peut effectuer des traitements des données reçus de la dernière opération E / S alors qu'un autre thread est en attente d'une nouvelle opération d'E/S et ne pas bloquer l'opération de E/S jusqu'a la fin de traitement.

• Priorité / ordonnancement temps-réel: les tâches qui sont plus importantes peuvent être prévues pour remplacer ou interrompre des tâches de moindre priorité.

• La gestion des événements asynchrones: Par exemple, un serveur web peut à la fois le transfert de données de demandes précédentes et à gérer l'arrivée de nouvelles demandes.

57

Page 58: Systèmes & Programmations Temps Réelle

Thread-safeThread-safe

• Si la routine n'emploie pas une sorte de synchronisation des actions pour empêcher la corruption de données, alors il n'est pas thread-safe.

58

Page 59: Systèmes & Programmations Temps Réelle

Pthreads API Pthreads API Création de threadCréation de threadint pthread_create(pthread_t *tid, const pthread_attr_t *tattr,void*(*start_routine)(void *),

void *arg); – Id du thread– Les attributs du thread– La fonction à executer– Le premier argument de la function à executer

#include <pthread.h>//fonction effectuant un traitementvoid *thr_f (void* param){int * t = (int *) param;printf ("parametre : %d", *t);}int main (){pthread_t thr1;pthread_create(&thr1,NULL,thr_f,arg);return 0;}

59

Page 60: Systèmes & Programmations Temps Réelle

Les attributs d’un thread :– le type d'ordonnancement– la priorité– la taille de la pile– Par défaut– SCHED OTHER : toutes les threads se partagent le– processeur en fonction de leur priorité.– Hérite de la priorité des parents (priorité=12, héritage=0)– Taille de la pile par défaut : 61440

 Modifier les attributs d'un thread

– Modifier l'ordonnancement :• int pthread_attr_setsched(pthread_attr_t *attr_pt, int

scheduler);– Modifier la priorité :

• int pthread_attr_setprio(pthread_attr_t *attr_pt, int prio);– Modifier la taille de la pile :

• int pthread_attr_setstacksize(pthread_attr_t *attr_pt, long size);

60

Page 61: Systèmes & Programmations Temps Réelle

Valeur du thread• pthread_t pthread_self(void); Renvoie la valeur du thread

appelant. Attendre qu'un thread se termine• int pthread_join(thread_t tid, void **status);

Suspend l'activité de la thread appelante tant que la thread tid n'est pas terminée.

status contient la valeur de retour du thread tid lors de sa terminaison.

 Rendre la main• int sched_yield(void);

Demander explicitement au cours de son ex_ecution de render la main

 Terminer une thread• void pthread_exit(void *status);

Termine l'exécution la thread courante avec une valeur de retour particulière

61

Page 62: Systèmes & Programmations Temps Réelle

Pthread condition variable

• Une thread mutex permet de synchroniser le contrôle des accès aux données critiques(section critique)

• Une thread variable de condition permet de synchroniser la valeur de ces données.

Autrement dit “Faire coopérer les threads et attendre que les données atteingnent un état particulier ou jusqu'à ce qu'un certain événement se produise.

Exemple :le thread du magasin doit attendre que le stock ne suffise plus aux clients pour le renflouer

62

Page 63: Systèmes & Programmations Temps Réelle

Créer une condition repose sur le même principe que les mutex à savoir, la création et initialisation d'une variable de type pthread_cond_t soit par exemple :static pthread_cond_t cond_stock = PTHREAD_COND_INITIALIZER ;

Les conditions reposent essentiellement sur deux fonctions : 1. Une permet de mettre en attente un thread 2. La seconde permet de signaler que la condition est remplie ce qui

réveille alors le thread qui est en attente de cette condition. pthread_cond_wait

int pthread_cond_wait (pthread_cond_t * cond, pthread_mutex_t * mutex);• L'adresse de la variable condition de type pthread_cond_t. • L'adresse d'un mutex. Une condition est en effet, toujours associée à un Une condition est en effet, toujours associée à un

mutex. mutex. pthread_cond_signal

int pthread_cond_signal (pthread_cond_t * cond); • pthread_cond_signal : la fonction qui permet de signaler la condition au thread qui

l'attend. Elle prend en paramètre l'adresse de la variable-condition surveillée. Cette fonction ne

permet de réveiller qu'un seul thread. Pour en réveiller d'avantage, il faut utiliser la fonction:

int pthread_cond_broadcast (pthread_cond_t * cond);

63

Page 64: Systèmes & Programmations Temps Réelle

Exercices :Pthread Condition Variable

Considérons deux variables globales partagées x et y=30, protégées par le mutex mt, et une variable condition cd pour signaler que x devient plus grand que y.

Soient deux threads : le thread Alarme qui se déclenche lorsque x > y et le thread X_inc qui incremente x.

1. Proposez le code du thread Alarme2. Proposez le code du thread X_inc3. Implémentez ce programme

64

Page 65: Systèmes & Programmations Temps Réelle

#include <stdlib.h>#include <stdio.h>#include <pthread.h>void* maFonction(void* data);int main(){ int i; // On crée un thread pthread_t thread; // Permet d'exécuter le fonction maFonction en parallèle

pthread_create(&thread, NULL, maFonction, NULL);

// Affiche 50 fois 1 for(i=0 ; i<50 ; i++) printf("1");

// Attend la fin du thread créé pthread_join(thread, NULL); return 0;}

void* maFonction(void* data){ int i; // Affiche 50 fois 2 for(i=0 ; i<50 ; i++) printf("2");

return NULL;}

65