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

Chap. 71 Chapitre 7 continuation n Problèmes classiques de synchronisation n Lecteurs - Écrivains n Les philosophes mangeant n Moniteurs n Threads en Java.

Présentations similaires


Présentation au sujet: "Chap. 71 Chapitre 7 continuation n Problèmes classiques de synchronisation n Lecteurs - Écrivains n Les philosophes mangeant n Moniteurs n Threads en Java."— Transcription de la présentation:

1 Chap. 71 Chapitre 7 continuation n Problèmes classiques de synchronisation n Lecteurs - Écrivains n Les philosophes mangeant n Moniteurs n Threads en Java

2 Chap. 72 n Dorénavant: u SC = Critical Section

3 Chap. 73 Sémaphores: rappel (les boîtes représentent des séquences indivisibles) acquire(S): S.value --; if S.value < 0 { // SC occupée ajouter ce thread à S.list; block // thread mis en état attente (wait) } release(S): S.value ++; if S.value 0 { // des threads attendent dans la file enlever un thread P de S.list; wakeup(P) // thread choisi devient prêt } S.value doit être initialisé à une valeur non-négative dépendant de lapplication, v. exemples

4 Chap. 74 Sémaphores: rappel. n Soit S un sémaphore sur une SC u il a une valeur S.value u il a une file d attente S.list u S positif: S thread peuvent entrer dans SC u S zéro: aucun thread ne peut entrer, aucun thread en attente u S négatif: |S| thread dans file dattente n acquire(S): S - - u si après S >= 0, thread peut entrer dans SC u si S < 0, thread est mis dans file d attente n release(S): S++ u si après S<= 0, il y avait des threads en attente, et un thread est transféré à la file prêt n Indivisibilité = atomicité dacquire et release

5 Chap. 75 Problème des lecteurs - écrivains n Plusieurs threads peuvent accéder à une base de données u Pour y lire ou pour y écrire n Les écrivains doivent être synchronisés entre eux et par rapport aux lecteurs u il faut empêcher à un thread de lire pendant une écriture u il faut empêcher à deux écrivains décrire simultanément n Les lecteurs peuvent y accéder simultanément n Exemple dapplication: u La base de données dun ministère, lue quotidiennement par des milliers de personnes u Elle doit aussi être mise à jour régulièrement

6 Chap. 76 Idée de solution n La base de données doit être protégée par un sémaphore pour synchroniser les écrivains entre eux et les lecteurs par rapport aux écrivains u Sémaphore db n Les écrivains doivent attendre sur db u les uns pour les autres u et aussi la fin de toutes les lectures n Les lecteurs doivent u attendre sur db quand il y a des écrivains qui écrivent u bloquer les écrivains sur db quand il y a des lecteurs qui lisent u redémarrer les écrivains quand personne ne lit n Quand un premier lecteur réussit à avoir la base de données, il faut permettre aux autres daussi lire mais il faut savoir combien de lecteurs actifs il y a, car quand il ny a plus de lecteurs actifs il faut permettre aux écrivains de reprendre u Il faut donc prévoir une variable pour compter les lecteurs: F readerCount u And un sémaphore pour protéger cette variable F Mutex (autre solution: reader count pourrait être un sémaphore)

7 Chap. 77 Éléments de solution n Sémaphore db: exclusion mutuelle entre écrivains et lecteurs n Variable readerCount: nombre de threads lisant la base de données u Pas un sémaphore n Sémaphore mutex: protège la SC où readerCount est mis à jour

8 Chap. 78 Les données et les écrivains Données: deux sémaphores et une variable mutex, db: semaphore (init. 1); readerCount : integer (init. 0); Écrivain acquire(db);... // écriture... release(db);

9 Chap. 79 Les lecteurs acquire(mutex); readerCount ++ ; if readerCount == 1 then acquire(db); release(mutex); //SC: lecture acquire(mutex); readerCount -- ; if readerCount == 0 then release(db); release(mutex): Le premier lecteur d un groupe pourrait devoir attendre sur db, il doit aussi bloquer les écrivains. Quand il sera entré, les lect. suivants pourront entrer librement Le dernier lecteur sortant doit permettre l`accès aux écrivains Avant lecture Après lecture

10 Chap. 710 Observations n Le 1er lecteur qui entre dans la SC bloque les écrivains u acquire (db) n le dernier les libère u release (db) n si 1 écrivain est dans la SC, 1 lecteur attend sur db, les autres sur mutex n un release(db) peut faire exécuter un lecteur ou un écrivain

11 Chap. 711 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 threads tout en évitant interblocage et famine

12 Chap. 712 Le problème des philosophes mangeant n Un thread 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 acquire(fork[i]) Thread Pi: repeat think; acquire(fork[i]); acquire(fork[i+1 mod 5]); eat; release(fork[i+1 mod 5]); release(fork[i]); forever

13 Chap. 713 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! Thread Pi: repeat think; acquire(T); acquire(fork[i]); acquire(fork[i+1 mod 5]); eat; release(fork[i+1 mod 5]); release(fork[i]); release(T); forever

14 Exercice Supposons que lensemble des philosophe soit partitionné en deux sous-ensembles non-vides: Philosophes gauchers, qui débutent toujours avec la fourchette gauche Philosophes droitiers, qui débutent toujours avec la fourchette droite Montrez quun interblocage ne sera pas possible. Après avoir étudié le chapitre sur linterblocage, déterminer quel est le principe qui nie la possibilité dinterblocage dans ce cas. Chap. 714

15 Chap. 715 Avantage des sémaphores (par rapport aux solutions précédentes) n Une seule variable partagée par section critique (la variable sémaphore) n deux seules opérations: acquire, release n contrôle plus localisé (que avec les précéds) n extension facile au cas de plus. threads n possibilité de faire entrer plus. threads à 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)

16 Chap. 716 Problème avec sémaphores: difficulté de programmation n acquire et release sont dispersés parmi plusieurs threads, mais ils doivent se correspondre u Utilisation doit être correcte dans tous les threads n Un seul mauvais thread peut faire échouer toute une collection de threads (p.ex. oublie de faire release) n Considérez le cas d`un thread qui a des acquire et release dans des boucles et des tests...

17 Chap. 717 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)

18 Chap. 718 Moniteur (= méthode synchronisée) 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 thread entre dans le moniteur en invoquant une de ses procédures u un seul thread peut exécuter dans le moniteur à tout instant (mais plus. threads peuvent être en attente dans le monit.)

19 Chap. 719 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 thread y entre

20 Chap. 720 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}... }

21 Chap. 721 Moniteur: Vue schématique simplifiée style Java

22 Chap. 722 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 thread exécutant sur la condition x F le thread pourra reprendre lexécution seulement si un autre thread exécute x: signal) u x: signal reprend lexécution dun thread bloqué sur la condition x F Sil en existe plusieurs: en choisir un (file?) F Sil nen existe pas: ne rien faire wait, signal: semblables à acquire, release

23 Chap. 723 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

24 Chap. 724 Blocage dans les moniteurs n threads attendent dans la file dentrée ou dans une file de condition (ils nexécutent pas) n sur x.wait: le thread est placé dans la file de la condition (il n exécute pas) n x.signal active 1 thread bloqué dans la file x (si x vide, aucun effet)

25 Chap. 725 Un détail concernant le signal n Quand un thread 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

26 Chap. 726 Prod/Cons: 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|)

27 Chap. 727 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

28 Chap. 728 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; Produce(v): if (count==k) notfull.wait; buffer[nextin] = v; nextin = (nextin+1 mod k); count ++; notempty.signal; Consume(v): if (count==0) notempty.wait; v = buffer[nextout]; nextout = (nextout+1 mod k); count --; notfull.signal; Variable conditionnelle sur laquelle le producteur attend sil ny a pas despaces libres (count==k) Variable conditionnelle sur laquelle le consommateur attend sil ny a pas despaces occupés

29 Comparaison avec la solution sémaphores n Étant donné que le moniteur assure à lui- même quun seul proc à la fois soit actif dans la SC, nous navons pas besoin dun mécanisme pour ceci u Dans la solution sémaphores ce mécanisme était assuré par le sémaphore M u Ici nous navons besoin que de deux variables F notfull correspondant au sémaphore E F notempy, correspondant au sémaphore F u Solution donc plus simple et intuitive avec les moniteurs quavec les sémaphores Chap. 729

30 Chap. 730 Terminologie Java (davantage au lab) n Les méthodes synchronisées de Java sont essentiellement des moniteurs u Un seul thread à la fois peut les exécuter n Il y a 2 files pour un objet: u File dentrée u File dattente (en attente sur wait) n Une méthode ne peut avoir que 1 file wait u Limitation importante qui complique les choses en Java… n Wait (acquérir) existe en Java + ou – comme décrit pour les moniteurs n Signal sappelle notify u Notify() libère 1 seul thread, il devient runnable u Notifyall fait la même chose pour tous u Mais ils nexécutent pas nécessairement: F ils sont remis dans la file dentrée

31 Chap. 731 Java: diagramme simplifié de transition détat threads (sur la base de la fig du manuel) nouveau start stop ou term. de run Sleep Wait I/O join suspend notify Fin E/S resume nouveau exécutable = runnable mort b loqué = not runnable bloqué sur une file associée à un événement prêt ou en exécution

32 Chap. 732 Un diagramme plus complet NEW READY RUNNING DEAD NOT RUNNABLE new start complète run method ou exception pas traitée Ordonnanceur choisit fil yield ou terminaison tranche ou préemption Notify, E/S terminée, resume, interrupted Sleep, wait, I/O, join, suspend RUNNABLE = READY ou RUNNING Les méthodes suspend, resume, stop ne sont pas recommandées aujourdhui (deprecated).

33 Chap. 733 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 threads tout en évitant interblocage et famine

34 Chap. 734 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

35 Chap. 735 Chaque philosophe exécute à jamais: repeat pickup eat putdown forever

36 Chap. 736 La solution Java est plus compliquée que la solution «moniteurs» surtout à cause du fait que Java na pas de variables conditionnelles nommées V. manuel

37 Chap. 737 Relation entre moniteurs et autre mécanismes n Les moniteurs sont implantés utilisant les sémaphores ou les autres mécanismes déjà vus n Il est aussi possible d`implanter les sémaphores en utilisant les moniteurs! u les laboratoires vont discuter ça

38 Chap. 738 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

39 Chap. 739 Synchronisation en Solaris 2 (avec UCT multiples) n Plusieurs mécanismes utilisés: u adaptive mutex protège l accès aux données partagées pour des SC courtes u sémaphores et condition variables protègent des SC plus importantes u serrures lecteurs-écrivains (reader-writers locks) protègent des données qui normalement ne sont que lues u les mêmes mécanismes sont disponibles aux usagers et dans le noyau

40 Chap. 740 Adaptive mutex en Solaris 2 n Utilisés pour des SC courtes: quand un thread veut accéder à des données partagées: u Si les données sont couramm. utilisées par un thread exécutant sur un autre UCT, l autre thread fait une attente occupée u Sinon, le thread est mis dans une file d attente et sera réveillé quand les données deviennent disponibles

41 Chap. 741 Windows NT: aussi plus. mécanismes n exclusion mutuelle sur données partagées: un fil doit demander accès et puis libérer n section critiques: semblables mais pour synchroniser entre fils de threads différents n sémaphores n event objects: semblables à condition variables

42 Chap. 742 Concepts importants du Chapitre 7 n Sections critiques: pourquoi n Difficulté du problème de la synch sur SC u Bonnes et mauvaises solutions n Accès atomique à la mémoire n Solutions logiciel `pures` n Solution matériel: test-and-set n Solutions par appels du système: u Sémaphores, moniteurs, fonctionnement n Problèmes typiques: tampon borné, lecteurs-écrivains, philosophes

43 Chap. 743 Par rapport au manuel n Le manuel couvre + ou – la même matière, mais en utilisant une approche Java n Pour le test et examen, suivre ma présentation u Ce que jai expliqué en classe n Pour les travaux de programmation, utiliser les exemples du manuel n Sections 7.9 et 7.10 ne sont pas matière dexamen

44 Deux grands informaticiens n Edsger W. Dijkstra ( ), hollandais, a inventé plusieurs idées fondamentales en informatique, entre autres les sémaphores n Tony Hoare (1934- ), anglais, aussi a inventé beaucoup de concepts fondamentaux, entre autres les moniteurs Chap. 744


Télécharger ppt "Chap. 71 Chapitre 7 continuation n Problèmes classiques de synchronisation n Lecteurs - Écrivains n Les philosophes mangeant n Moniteurs n Threads en Java."

Présentations similaires


Annonces Google