La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Synchronisation de Processus Chapitre 5. 2 Synchronisation de Processus 1. Conditions de Concurrence 2. Sections Critiques 3. Exclusion Mutuelle 4.

Présentations similaires


Présentation au sujet: "1 Synchronisation de Processus Chapitre 5. 2 Synchronisation de Processus 1. Conditions de Concurrence 2. Sections Critiques 3. Exclusion Mutuelle 4."— Transcription de la présentation:

1 1 Synchronisation de Processus Chapitre 5

2 2 Synchronisation de Processus 1. Conditions de Concurrence 2. Sections Critiques 3. Exclusion Mutuelle 4. Sommeil & Activation 5. Sémaphores 6. Mutex 7. Moniteurs

3 3 Problèmes avec concurrence = parallélisme n Les processus concurrents doivent parfois partager données (fichiers ou mémoire commune) et ressources u On parle donc de tâches coopératives n Si laccès nest pas contrôlé, le résultat de lexécution du programme pourra dépendre de lordre dentrelacement de lexécution des instructions (non- déterminisme). n Un programme pourra donner des résultats différents et parfois indésirables

4 4 Un exemple n Deux processus exécutent cette même procédure et partagent la même base de données n Ils peuvent être interrompus nimporte où n Le résultat de lexécution concurrente de P1 et P2 dépend de lordre de leur entrelacement M. X demande une réservation davion Base de données dit que fauteuil A est disponible Fauteuil A est assigné à X et marqué occupé

5 5 Vue globale dune exécution possible M. Guy demande une réservation davion Base de données dit que fauteuil 30A est disponible Fauteuil 30A est assigné à Guy et marqué occupé M. Leblanc demande une réservation davion Base de données dit que fauteuil 30A est disponible Fauteuil 30A est assigné à Leblanc et marqué occupé Interruption ou retard P1 P2

6 6 Deux opérations en parallèle sur une var a partagée (b est privé à chaque processus) b=a b++ a=b b=a b++ a=b P1 P2 Supposons que a soit 0 au début P1 travaille sur le vieux a donc le résultat final sera a=1. Serait a=2 si les deux tâches sont exécutées lune après lautre Si a était sauvegardé quand P1 est interrompu, il ne pourrait pas être partagé avec P2 (il y aurait deux a tandis que nous en voulons une seule) interruption

7 7 Section Critique n Partie dun programme dont lexécution ne doit pas entrelacer avec autres programmes n Une fois quun tâche y entre, il faut lui permettre de terminer cette section sans permettre à autres tâches de jouer sur les mêmes données

8 8 Le problème de la section critique n Lorsquun processus manipule une donnée (ou ressource) partagée, nous disons quil se trouve dans une section critique (SC) (associée à cette donnée) n Le problème de la section critique est de trouver un algorithme d`exclusion mutuelle de processus dans l`exécution de leur SCs afin que le résultat de leurs actions ne dépendent pas de lordre dentrelacement de leur exécution (avec un ou plusieurs processeurs) n Lexécution des sections critiques doit être mutuellement exclusive: à tout instant, un seul processus peut exécuter une SC pour une var donnée (même lorsquil y a plusieurs processeurs) n Ceci peut être obtenu en plaçant des instructions spéciales dans les sections d`entrée et sortie n Pour simplifier, dorénavant nous faisons lhypothèse quil ny a qune seule SC dans un programme.

9 9 Structure du programme n Chaque processus doit donc demander une permission avant dentrer dans une section critique (SC) n La section de code qui effectue cette requête est la section dentrée n La section critique est normalement suivie dune section de sortie n Le code qui reste est la section restante (SR): non-critique repeat section dentrée section critique section de sortie section restante forever

10 10 Application M. X demande une réservation davion Section dentrée Base de données dit que fauteuil A est disponible Fauteuil A est assigné à X et marqué occupé Section de sortie Section critique

11 11 Critères nécessaires pour solutions valides n Exclusion Mutuelle u À tout instant, au plus un processus peut être dans une section critique (SC) pour une variable donnée n Non interférence: u Si un processus sarrête dans sa section restante, ceci ne devrait pas affecter les autres processus n Mais on fait lhypothèse quun processus qui entre dans une section critique, en sortira.

12 12 Critères nécessaires pour solutions valides n Progrès: u absence d`interblocage (Chap 6) u si un processus demande d`entrer dans une section critique à un moment où aucun autre processus en fait requête, il devrait être en mesure dy entrer n Absence de famine: aucun processus éternellement empêché datteindre sa SC n Difficile à obtenir, nous verrons…

13 13 Conditions de Concurrence n Conditions de concurrence (race conditions): situation où 2 processus ou plus effectuent des lectures et des écritures conflictuelles. n Exemple du Spouler dimpression u Un processus qui veut imprimer un fichier, entre son nom dans un répertoire de spoule u Le processus démon dimpression regarde périodiquement sil y a des fichiers à imprimer. Il a 2 variables: F in: pointe vers la prochaine entrée libre. F out: pointe vers le prochain fichier à imprimer u in = 7, out = 4 u A et B deux processus qui veulent imprimer un fichier u A >> lire in, next_free_slot = 7 u Interruption: la CPU bascule vers le processus B u B >> lire in, next_free_slot = 7, entrée7 = fichierB, in = 8 u A >> entrée7 = fichierA, in = 8 u Problème: le fichierB ne sera pas imprimé

14 14 … Conditions de Concurrence n Comment éviter les conditions de concurrence? n Solution: Interdire que plusieurs processus lisent et écrivent des données partagées simultanément. n Exclusion Mutuelle: permet dassurer que si un processus utilise une variable ou fichier partagés, les autres processus seront exclus de la même activité

15 15 Les Sections Critiques A B t1t2t3t4 A entre dans sa section critique B tente dentrer dans sa section critique A quitte sa section critique B entre dans sa section critique B quitte sa section critique les Sections Critiques, méthode dexclusion mutuelle

16 16 LExclusion Mutuelle avec Attente Active ( busy waiting ) n Désactivation des interruptions u Après son entrée dans une SC, un processus désactive les interruptions, puis les réactive u Il empêche ainsi lhorloge denvoyer des interruptions et le processeur de basculer u Il est imprudent de permettre à des processus user de désactiver les interruptions n Variables de verrou (lock) u Avant dentrer en SC, tester la valeur de verrou, si verrou = 0, verrou 1, entrer en SC u Défaillance: 2 processus peuvent entrer simultanément dans leurs sections critiques comme le spouler dimpression n Alternance Stricte u la variable turn porte le numéro du processus dont cest le tour dentrer en SC. Chaque processus inspecte la valeur de la variable, avant dentrer en SC. u Inconvénient: consomme bcp de temps CPU

17 17 … Exclusion Mutuelle avec Attente Active ( busy waiting ) n … Alternance Stricte while (TRUE) { while (turn != 0); while (turn != 1); critical_region(); critical_region(); turn = 1; turn = 0; non_critical_region(); non_critical_region(); } u Les attentes actives sont performantes dans le cas où elles sont brèves. En effet, il y a risque dattente F P0 quitte la CS, turn = 1 F P1 termine sa CS, turn = 0 F Les 2 processus sont en section non critique F P0 exécute sa boucle, quitte la SC et turn = 1 F Les 2 processus sont en section non critique F P0 quoiquil a terminé, il ne peut pas entrer en SC, il est bloqué

18 18 … Sommeil & Activation n Problème de blocage: u Le consommateur note que le tampon est vide u Interruption: arrêt du consommateur sans quil parte en sommeil u Le producteur insère un jeton, incrémente le décompte, appelle wakeup pour réveiller le consommateur u Le signal wakeup est perdu, car le consommateur nest pas en sommeil u Le consommateur reprend, pour lui le tampon est vide, il dort u Le producteur remplit le tampon et dort n Solution: ajouter un bit dattente déveil. u Quand un wakeup est envoyé à un processus le bit est à 1; u le consommateur teste le bit, sil est à 1, il le remet à 0 et reste en éveil u Cette solution est + difficile à généraliser en cas de + sieurs processus.

19 19 Une leçon à retenir… n À fin que des processus avec des variables partagées puissent réussir, il est nécessaire que tous les processus impliqués utilisent le même algorithme de coordination u Un protocole commun

20 20 Critique des solutions par logiciel n Difficiles à programmer! Et à comprendre! u Les solutions que nous verrons dorénavant sont toutes basées sur lexistence dinstructions spécialisées, qui facilitent le travail. n Les processus qui requièrent lentrée dans leur SC sont occupés à attendre (busy waiting); consommant ainsi du temps de processeur u Pour de longues sections critiques, il serait préférable de bloquer les processus qui doivent attendre...

21 21 Solutions matérielles: désactivation des interruptions n Sur un uniprocesseur: exclusion mutuelle est préservée mais lefficacité se détériore: lorsque dans SC il est impossible dentrelacer lexécution avec dautres processus dans une SR n Perte dinterruptions n Sur un multiprocesseur: exclusion mutuelle nest pas préservée n Une solution qui nest généralement pas acceptable Process Pi: repeat inhiber interrupt section critique rétablir interrupt section restante forever

22 22 Solutions basées sur des instructions fournies par le SE (appels du système) n Les solutions vues jusquà présent sont difficiles à programmer et conduisent à du mauvais code. n On voudrait aussi qu`il soit plus facile déviter des erreurs communes, comme interblocages, famine, etc. u Besoin dinstruction à plus haut niveau n Les méthodes que nous verrons dorénavant utilisent des instructions puissantes, qui sont implantées par des appels au SE (system calls)

23 23 Sémaphores n Un sémaphore S est un entier qui, sauf pour l'Initialisation, est accessible seulement par ces 2 opérations atomiques et mutuellement exclusives: u wait(S) u signal(S) n Il est partagé entre tous les procs qui s`intéressent à la même section critique n Les sémaphores seront présentés en deux étapes: u sémaphores qui sont occupés à attendre (busy waiting) u sémaphores qui utilisent des files d attente n On fait distinction aussi entre sémaphores compteurs et sémaphores binaires, mais ce derniers sont moins puissants.

24 24 Sémaphores occupés à attendre (busy waiting) n La façon la plus simple dimplanter les sémaphores. n Utiles pour des situations où lattente est brève, ou il y a beaucoup dUCTs n S est un entier initialisé à une valeur positive, de façon que un premier processus puisse entrer dans la SC n Quand S>0, jusquà n processus peuvent entrer n Quand S<=0, il faut attendre S+1 signals (dautres processus) pour entrer wait(S): while S<=0 {}; S--; signal(S): S++; Attend si no. de processus qui peuvent entrer = 0 ou négatif Augmente de 1 le no des processus qui peuvent entrer

25 25 Atomicité Wait : La séquence test- décrément est atomique, mais pas la boucle! Signal est atomique. Rappel: les sections atomiques ne peuvent pas être exécutées simultanément par différent processus (ceci peut être obtenu un utilisant un des mécanismes précédents) S <= 0 atomique S - - F V SC

26 26 Atomicité et interruptibilité S <= 0 atomique S - - F V S++ La boucle nest pas atomique pour permettre à un autre processus dinterrompre lattente sortant de la SC interruptible autre Pro. SC

27 27 Utilisation des sémaphores pour sections critiques n Pour n processus n Initialiser S à 1 n Alors 1 seul processus peut être dans sa SC n Pour permettre à k processus dexécuter SC, initialiser S à k processus Ti: repeat wait(S); SC signal(S); SR forever

28 28 processus T1: repeat wait(S); SC signal(S); SR forever processus T2: repeat wait(S); SC signal(S); SR forever Semaphores: vue globale Initialise S à > =1 Peut être facilement généralisé à plus. processus

29 29 Utilisation des sémaphores pour synchronisation de processus n On a 2 processus : T1 et T2 n Énoncé S1 dans T1 doit être exécuté avant énoncé S2 dans T2 n Définissons un sémaphore S n Initialiser S à 0 n Synchronisation correcte lorsque T1 contient: S1; signal(S); n et que T2 contient: wait(S); S2;

30 30 Interblocage et famine avec les sémaphores n Famine: un processus peut narriver jamais à exécuter car il ne teste jamais le sémaphore au bon moment n Interblocage: Supposons S et Q initialisés à 1 T0 T1 wait(S) wait(Q) wait(Q) wait(S)

31 31 Sémaphores: observations n Quand S >= 0: u Le nombre de processus qui peuvent exécuter wait(S) sans devenir bloqués = S F S processus peuvent entrer dans la SC F noter puissance par rapport à mécanismes déjà vus F dans les solutions où S peut être > 1il faudra avoir un 2ème sém. pour les faire entrer un à la fois (excl. mutuelle) n Quand S devient > 1, le processus qui entre le premier dans la SC est le premier à tester S (choix aléatoire) u ceci ne sera plus vrai dans la solution suivante n Quand S < 0: le nombre de processus qui attendent sur S est = |S| wait(S): while S<=0 {}; S--;

32 32 Comment éviter lattente occupée et le choix aléatoire dans les sémaphores n Quand un processus doit attendre quun sémaphore devienne plus grand que 0, il est mis dans une file dattente de processus qui attendent sur le même sémaphore. n Les files peuvent être PAPS (FIFO), avec priorités, etc. Le SE contrôle l`ordre dans lequel les processus entrent dans leur SC. n wait et signal sont des appels au SE comme les appels à des opérations dE/S. n Il y a une file dattente pour chaque sémaphore comme il y a une file dattente pour chaque unité dE/S.

33 33 Sémaphores sans attente occupée n Un sémaphore S devient une structure de données: u Une valeur u Une liste dattente L n Un processus devant attendre un sémaphore S, est bloqué et ajouté la file dattente S.L du sémaphore (v. état bloqué = attente chap 4). n signal(S) enlève (selon une politique juste, ex: PAPS/FIFO) un processus de S.L et le place sur la liste des processus prêts/ready.

34 34 Implementation (les boîtes réprésentent des séquences non-interruptibles) wait(S):S.value --; if S.value < 0 { // SC occupée add this processus to S.L; block // processus mis en état attente (wait) } signal(S): S.value ++; if S.value 0 { // des processus attendent remove a process P from S.L; wakeup(P) // processus choisi devient prêt } S.value doit être initialisé à une valeur non- négative (dépendant de lapplication, v. exemples)

35 35 Figure montrant la relation entre le contenu de la file et la valeur de S Quand S < 0: le nombre de processus qui attendent sur S est = |S|

36 36 Wait et signal contiennent elles mêmes des SC! n Les opérations wait et signal doivent être exécutées atomiquement (un seul thr. à la fois) n Dans un système avec 1 seule UCT, ceci peut être obtenu en inhibant les interruptions quand un processus exécute ces opérations n Lattente occupée dans ce cas ne sera pas trop onéreuse car wait et signal sont brefs

37 37 Problèmes classiques de synchronisation n Tampon borné (producteur-consommateur) n Écrivains - Lecteurs n Les philosophes mangeant

38 38 Le pb du producteur - consommateur n Un problème classique dans l étude des processus communicants u un processus producteur produit des données (p.ex.des enregistrements d un fichier) pour un processus consommateur

39 39 Tampons de communication Prod Cons 1 donn Prod Cons 1 donn Si le tampon est de longueur 1, le producteur et consommateur doivent forcement aller à la même vitesse Des tampons de longueur plus grandes permettent une certaine indépendance. P.ex. à droite le consommateur a été plus lent

40 40 Le tampon borné (bounded buffer) une structure de données fondamentale dans les SE b[0] b[1] b[7]b[2] b[6]b[3] b[4]b[5] ou out: 1ère pos. pleine in: 1ère pos. libre b[0] b[1]b[7]b[2]b[6]b[3]b[4]b[5] in: 1ère pos. libre out: 1ère pos. pleine bleu: plein, blanc: libre Le tampon borné se trouve dans la mémoire partagée entre consommateur et usager

41 41 Pb de sync entre processus pour le tampon borné n Étant donné que le prod et le consommateur sont des processus indépendants, des problèmes pourraient se produire en permettant accès simultané au tampon n Les sémaphores peuvent résoudre ce problème

42 42 Sémaphores: rappel. n Soit S un sémaphore sur une SC u il est associé à une file d attente u S positif: S processus peuvent entrer dans SC u S zéro: aucun processus ne peut entrer, aucun processus en attente u S négatif: |S| processus dans file d attente n Wait(S): S - - u si après S >= 0, processus peut entrer dans SC u si S < 0, processus est mis dans file d attente n Signal(S): S++ u si après S<= 0, il y avait des processus en attente, et un processus est réveillé n Indivisibilité = atomicité de ces ops

43 43 Solution avec sémaphores n Un sémaphore S pour exclusion mutuelle sur laccès au tampon u Les sémaphores suivants ne font pas lEM n Un sémaphore N pour synchroniser producteur et consommateur sur le nombre déléments consommables dans le tampon n Un sémaphore E pour synchroniser producteur et consommateur sur le nombre despaces libres

44 44 Solution de P/C: tampon circulaire fini de dimension k Initialization: S.count=1; //excl. mut. N.count=0; //esp. pleins E.count=k; //esp. vides Producer: repeat produce v; wait(E); wait(S); append(v); signal(S); signal(N); forever Consumer: repeat wait(N); wait(S); w=take(); signal(S); signal(E); consume(w); forever Sections critiques append(v): b[in]=v; In ++ mod k; take(): w=b[out]; Out ++ mod k; return w;

45 45 Points importants à étudier n dégâts possibles en interchangeant les instructions sur les sémaphores u ou en changeant leur initialisation n Généralisation au cas de plus. prods et cons

46 46 Problème des lecteurs - rédacteurs n Plusieurs processus peuvent accéder à une base de données u Pour y lire ou pour y écrire n Les rédacteurs doivent être synchronisés entre eux et par rapport aux lecteurs u il faut empêcher à un processus de lire pendant lécriture u il faut empêcher à deux rédacteurs d écrire simultanément n Les lecteurs peuvent y accéder simultanément

47 47 Une solution (nexclut pas la famine) n Variable readcount: nombre de processus lisant la base de données n Sémaphore mutex: protège la SC où readcount est mis à jour n Sémaphore wrt: exclusion mutuelle entre rédacteurs et lecteurs n Les rédacteurs doivent attendre sur wrt u les uns pour les autres u et aussi la fin de toutes les lectures n Les lecteurs doivent u attendre sur wrt quand il y a des rédacteurs qui écrivent u bloquer les rédacteurs sur wrt quand il y a des lecteurs qui lisent u redémarrer les rédacteurs quand personne ne lit

48 48 Les données et les rédacteurs Données: deux sémaphores et une variable mutex, wrt: semaphore (init. 1); readcount : integer (init. 0); Rédacteur wait(wrt);... // écriture... signal(wrt);

49 49 Les lecteurs wait(mutex); readcount ++ ; if readcount == 1 then wait(wrt); signal(mutex); //SC: lecture wait(mutex); readcount -- ; if readcount == 0 then signal(wrt); signal(mutex): Le premier lecteur d un groupe pourrait devoir attendre sur wrt, il doit aussi bloquer les rédacteurs. Quand il sera entré, les suivants pourront entrer librement Le dernier lecteur sortant doit permettre l`accès aux rédacteurs

50 50 Observations n Le 1er lecteur qui entre dans la SC bloque les rédacteurs (wait (wrt)), le dernier les remet en marche (signal (wrt)) n Si 1 rédacteur est dans la SC, 1 lecteur attend sur wrt, les autres sur mutex n un signal(wrt) peut faire exécuter un lecteur ou un rédacteur

51 51 Le problème des philosophes mangeant n 5 philosophes qui mangent et pensent n Pour manger il faut 2 fourchettes, droite et gauche n On en a seulement 5! n Un problème classique de synchronisation n Illustre la difficulté dallouer ressources aux processus tout en évitant interblocage et famine

52 52 Le problème des philosophes mangeant n Un processus par philosophe n Un sémaphore par fourchette: u fork: array[0..4] of semaphores u Initialisation: fork[i ] =1 for i:=0..4 n Première tentative: u interblocage si chacun débute en prenant sa fourchette gauche! F Wait(fork[i]) processus Pi: repeat think; wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); forever

53 53 Le problème des philosophes mangeant n Une solution: admettre seulement 4 philosophes à la fois qui peuvent tenter de manger n Il y aura touj. au moins 1 philosophe qui pourra manger u même si tous prennent 1 fourchette n Ajout dun sémaphore T qui limite à 4 le nombre de philosophes assis à la table u initial. de T à 4 n Nempêche pas famine! processus Pi: repeat think; wait(T); wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); signal(T); forever

54 54 Avantage des sémaphores (par rapport aux solutions précédentes) n Une seule variable partagée par section critique n deux seules opérations: wait, signal n contrôle plus localisé (que avec les précéds) n extension facile au cas de plus. processus n possibilité de faire entrer plus. processus à la fois dans une section critique n gestion de files d`attente par le SE: famine évitée si le SE est équitable (p.ex. files FIFO)

55 55 Problème avec sémaphores: difficulté de programmation n wait et signal sont dispersés parmi plusieurs processus, mais ils doivent se correspondre u V. programme du tampon borné n Utilisation doit être correcte dans tous les processus n Un seul mauvais processus peut faire échouer toute une collection de processus (p.ex. oublie de faire signal) n Considérez le cas d`un processus qui a des waits et signals dans des boucles et des tests...

56 56 Moniteurs: une autre solution n Constructions (en langage de haut-niveau) qui procurent une fonctionnalité équivalente aux sémaphores mais plus facile à contrôler n Disponibles en: F Concurrent Pascal, Modula-3... synchronized method en Java (moniteurs simplifiés)

57 57 Moniteur n Est un module contenant: u une ou plusieurs procédures u une séquence dinitialisation u variables locales n Caractéristiques: u variables locales accessibles seulement à laide dune procédure du moniteur u un processus entre dans le moniteur en invoquant une de ses procédures u un seul processus peut exécuter dans le moniteur à tout instant (mais plus. processus peuvent être en attente dans le monit.)

58 58 Moniteur n Il assure à lui seul lexclusion mutuelle: pas besoins de le programmer explicitement n On assure la protection des données partagées en les plaçant dans le moniteur u Le moniteur verrouille les données partagées lorsquun processus y entre n Synchronisation de processus est effectuée en utilisant des variables conditionnelles qui représentent des conditions après lesquelles un processus pourrait attendre avant dexécuter dans le moniteur

59 59 Structure générale du moniteur (style Java) La seule façon de manipuler les vars internes au moniteur est dappeler une des méthodes dentrée monitor nom-de-moniteur { // déclarations de vars public entry p1(...) {code de méthode p1} public entry p2(...) {code de méthode p2}... }

60 60 Moniteur: Vue schématique simplifiée style Java

61 61 Variables conditionnelles (nexistent pas en Java) n sont accessibles seulement dans le moniteur n accessibles et modifiables seulement à laide de 2 fonctions: u x: wait bloque lexécution du processus exécutant sur la condition x F le processus pourra reprendre lexécution seulement si un autre processus exécute x: signal) u x: signal reprend lexécution dun processus bloqué sur la condition x F Sil en existe plusieurs: en choisir un (file?) F Sil nen existe pas: ne rien faire

62 62 Moniteur avec variables conditionnelles Dans une banque, il y a une file principale, mais une fois entré on pourrait vous faire attendre dans un fauteuil jusquà ce que le préposé soit disponible

63 63 Un concept plus général: Variables condition n On appelle variable condition une var qui peut être testée et u endorme le processus qui la teste si la condition est fausse u le réveille quand la condition devient vraie n Sont employées dans les moniteurs, mais peuvent aussi être utilisées indépendamment

64 64 Blocage dans les moniteurs n processus attendent dans la file dentrée ou dans une file de condition (ils n exécutent pas) n sur x.wait: le processus est placé dans la file de la condition (il n exécute pas) n x.signal amène dans le moniteur 1 processus de la file x (si x vide, aucun effet)

65 65 Un pb concernant le signal n Quand un processus P exécute x.signal et libère un thr. Q, il pourrait y avoir 2 thr. qui peuvent exécuter, P et Q, ce qui est défendu. Deux solutions possibles: u P pourrait attendre jusqu` à ce que Q sorte du moniteur, p.ex. dans une file spéciale (dite urgente) (v. Stallings) u Q pourrait attendre jusquà ce que P sorte du moniteur

66 66 Retour au problème des philosophes mangeant n 5 philosophes qui mangent et pensent n Pour manger il faut 2 baguettes, droite et gauche n On en a seulement 5! n Un problème classique de synchronisation n Illustre la difficulté dallouer ressources aux processus tout en évitant interblocage et famine

67 67 Philosophes mangeant structures de données n Chaque philos. a son propre state qui peut être (thinking, hungry, eating) u philosophe i peut faire state[i] = eating ssi les voisins ne mangent pas n Chaque condition a sa propre condition self u le philosophe i peut attendre sur self [ i ] si veut manger, mais ne peut pas obtenir les 2 baguettes

68 68 Chaque philosophe exécute à jamais: repeat pickup eat putdown forever

69 69 private test(int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING; self[i].signal; } Un philosophe mange Un philosophe mange si ses voisins ne mangent pas et sil a faim. Une fois mangé, il signale de façon quun autre pickup soit possible, si pickup sétait arrêté sur wait Il peut aussi sortir sans avoir mangé si le test est faux

70 70 Chercher de prendre les baguettes public entry pickUp(int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self[i].wait; } Phil. cherche à manger en testant, sil sort de test quil nest pas mangeant il attend – un autre pickup nest pas possible avant un self[i] signal

71 71 Déposer les baguettes public entry putDown(int i) { state[i] = THINKING; // tester les deux voisins test((i + 4) % 5); test((i + 1) % 5); } Une fois fini de manger, un philosophe se préoccupe de faire manger ses voisins en les testant

72 72 P/C: tampon circulaire de dimension k n Peut consommer seulement si le nombre N déléments consommables est au moins 1 (N = in-out) n Peut produire seulement si le nombre E despaces libres est au moins 1 (E = out-in)

73 73 Variables conditionnelles utilisées n Si le tampon est plein, le producteur doit attendre quil devienne non-plein u Var conditionnelle notfull n Si le tampon est vide, le consommateur doit attendre quil devienne non-vide u Var conditionnelle notempty

74 74 Moniteur pour P/C avec tampon fini (syntaxe un peu différente, pas orienté objet) Monitor boundedbuffer: buffer: vecteur[0..k-1] de items; nextin = 0, nextout = 0, count = 0 ; notfull, notempty: condition; Append(v): if (count==k) notfull.wait; buffer[nextin] = v; nextin = (nextin+1 mod k); count ++; notempty.signal; Take(v): if (count==0) notempty.wait; v = buffer[nextout]; nextout = (nextout+1 mod k); count --; notfull.signal;

75 75 Le problème de la SC en pratique... n Les systèmes réels rendent disponibles plusieurs mécanismes qui peuvent être utilisés pour obtenir la solution la plus efficace dans différentes situations


Télécharger ppt "1 Synchronisation de Processus Chapitre 5. 2 Synchronisation de Processus 1. Conditions de Concurrence 2. Sections Critiques 3. Exclusion Mutuelle 4."

Présentations similaires


Annonces Google