Chap. 71 Synchronisation de Processus (ou de threads, fils ou tâches) Chapitre 7

Le problème Chap. 72

3 Problèmes avec concurrence = parallélisme n Les threads concurrents doivent parfois partager données (fichiers ou mémoire commune) et ressources u On parle donc de threads coopérants n Si l’accès n’est pas contrôlé, le résultat de l’exécution du programme pourra dépendre de l’ordre d’entrelacement de l’exécution des instructions (non-déterminisme). n Un programme pourra donner des résultats différents et parfois indésirables de fois en fois

Chap. 74 Exemple 1 n Deux threads exécutent cette même procédure et partagent la même base de données n Ils peuvent être interrompus n’importe où n Le résultat de l ’exécution concurrente de P1 et P2 dépend de l`ordre de leur entrelacement u Souvent bon, parfois mauvaix M. X demande une réservation d’avion Base de données dit que fauteuil A est disponible Fauteuil A est assigné à X et marqué occupé

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

Hypothèse de partage de données Chap. 76 Partagées entre threads Les données partagées ne sont pas souvegardées quand on change de thread

n Exécuter en parallèle avec lui-même le code suivant: n Quel pourrait être le résultat final dans a? u (il se peut qu’il n’y aura pas de pb cependant, dépendent de plusieurs facteurs) Exemple 2 Chap. 77 b=a b++ a=b

Chap. 78 b=a b++ a=b b=a b++ a=b P1 P2P2 Supposons que a soit 0 au début P1 travaille sur le vieux a donc le résultat final sera a=1. Sera a=2 si les deux tâches sont exécutées l’une après l’autre Cas pratique: a est un compteur d’accès dans une page web interruption Deux opérations en parallèle var a partagée entre thread var b est privée à chaque thread

Chap. 79 3ème exemple Thread P1 static char a; void echo() { cin >> a; cout << a; } Thread P2 static char a; void echo() { cin >> a; cout << a; } Si la var a est partagée, le premier a est effacé Si elle est privée, l’ordre d’affichage est renversé

Asynchronie des threads n Quand plusieurs threads exécutent en parallèle, nous ne pouvons pas faire d’hypothèses sur la vitesse d’exécution des threads, ni leur entrelacement n Peuvent être différents à chaque exécution du programme u Dont le non-déterminisme Chap. 710

Chap. 711 Autres exemples n Des threads qui travaillent en simultanéité sur une matrice, par ex. un pour la mettre à jour, l`autre pour en extraire des statistiques n Problème qui affecte le programme du tampon borné, v. manuel

Exercice n Dans un langage de programmation qui supporte la progr. parallèle, écrire un programme avec deux boucles en parallèle n Une boucle ne fait qu’afficher des A n Une autre boucle ne fait qu’afficher des B n À l’écran, vous devriez voir des A et des Bs parsemés de manière aléatoire n Pour voir bien ce résultat il pourrait être nécessaire d’inclure un ‘retard’ dans chaque boucle u Sinon, dépendant de l’ordonnanceur, vous pourriez voir p.ex fois A avant de voir le premier B u P.ex. en Java utiliser méthode Tread.sleep ce qui n’est pas très facile, voir aide dans le www n Ceux qui réussissent à faire ceci, SVP venez me voir … Chap. 712

Chap. 713 Section Critique n Partie d’un programme dont l’exécution ne doit pas entrelacer avec autres programmes u Indivisibilité ou atomicité de la section critique n Une fois qu’un processus ou fil y entre, il faut lui permettre de terminer cette section sans permettre à autres de jouer sur les mêmes données u La section critique doit être verrouillée afin de devenir atomique

Entrelacement de threads A et B Chap. 714 A A Contin. A Contin. B B contin Les flèches indiquent délais ou interruptions Beaucoup de possibilités, selon les points où A et B sont interrompus

Atomicité de threads A et B par effet du verrou Chap. 715 A B A B OU Seulement deux possibilités, quand chacun est exécuté sans interruptions

Section critique Chap. 716 M. X demande une réservation d’avion Base de données dit que fauteuil A est disponible Fauteuil A est assigné à X et marqué occupé atomique

Chap. 717 Le problème de la section critique n Lorsqu’un thread manipule une donnée (ou ressource) partagée avec autres, nous disons qu’il se trouve dans une section critique (associée à cette donnée) n Le problème de la section critique est de trouver un algorithme d`exclusion mutuelle de threads dans l`exécution de leur CritSect afin que le résultat de leurs actions ne dépendent pas de l’ordre d’entrelacement de leur exécution (avec un ou plusieurs processeurs) n L’exécution des sections critiques doit être mutuellement exclusive et atomique: à tout instant, un seul thread peut exécuter une CritSect pour une donnée (même lorsqu’il y a plusieurs UCT) n Ceci peut être obtenu en plaçant des instructions spéciales dans les sections d`entrée et sortie u Implantation du cadenas

Chap. 718 Deux simplifications n Pour simplifier, parfois nous ferons l’hypothèse qu’il n’y a qu’une seule CritSect dans un thread n Et nous ne ferons plus distinction entre CritSect pour différentes données

Chap. 719 Structure d’un programme type n Le programme est présenté comme boucle infinie: while(true) n Chaque thread doit donc demander une permission avant d’entrer dans une CritSect n La section de code qui effectue cette requête est la section d’entrée n La section critique est normalement suivie d’une section de sortie (leave CritSect) n Le code qui reste est la section non-critique while (true) { enterCritSect CritSect leaveCritSect nonCritSect } atomique

Chap. 720 Application (un programme qui répète à jamais) M. X demande une réservation d’avion enterCritSect Base de données dit que fauteuil A est disponible Fauteuil A est assigné à X et marqué occupé leaveCritSect Section critique

Chap. 721 Exigences pour solutions valides (*) n Exclusion Mutuelle u En tout moment, au plus un thread peut être dans une CritSect n Déroulement u Une CritSect ne sera donnée qu’à un thread qui attend d’y entrer u Chaque fois qu’une CritSect devient disponible, s’il y a des threads qui l’attendent, un d’eux doit être capable d’y entrer ( pas d’interblocage ) n Attente bornée (pas de famine) u Un thread qui attend d’entrer dans une CritSect pourra enfin y entrer F = aucun thread ne peut être exclu à jamais de la CritSect à cause d’autres threads qui la monopolisent n Notez la différence entre interblocage et famine (*) Définitions plus compliquée dans le manuel, mais selon moi sans besoin

Chap. 722 Trois types de solutions n Solutions par logiciel u des algorithmes qui n’utilisent pas d`instruction spéciales n Solutions fournies par le matériel u s’appuient sur l’existence de certaines instructions (du processeur) spéciales n Solutions fournies pas le SE u procure certains appels du système au programmeur n Toutes les solutions se basent sur l’atomicité de l’accès à la mémoire centrale: une adresse de mémoire ne peut être affectée que par une instruction à la fois, donc par un thread à la fois. n Plus en général, toutes les solutions se basent sur l’existence d’instructions atomiques, qui fonctionnent comme Sections Critiques de base

Solutions par logiciel pur Chap. 723

Un groupe d’étudiants collabore sur un devoir n Solution 1: u Ils se passent la copie du devoir dans un ordre fixe: F Marc, Ahmed, Marie, Marc, Ahmed, Marie … Chap. 724

Un groupe d’étudiants collabore sur un devoir n Solution 1: u Ils se passent la copie du devoir dans un ordre fixe: F Marc, Ahmed, Marie, Marc, Ahmed, Marie … n Solution 2: u Un étudiant passe la copie à un autre seulement si l’autre demande d’y travailler Chap. 725

Un groupe d’étudiants collabore sur un devoir n Solution 1: u Un étudiant passe la copie au prochain dans un ordre fixe: F Marc, Ahmed, Marie, Marc, Ahmed, Marie … n Solution 2: u Un étudiant passe la copie à un autre seulement si l’autre veut y travailler n Solution 3: u Combiner les idées des solutions précédentes Chap. 726

Chap. 727 Solutions par logiciel (pas pratiques, mais intéressantes pour comprendre le pb) n Nous considérons d’abord 2 threads u Algorithmes 1 et 2 ne sont pas valides F Montrent la difficulté du problème u Algorithme 3 est valide (algorithme de Peterson) n Notation u Débutons avec 2 threads: T0 et T1 u Lorsque nous discutons de la tâche Ti, Tj sera toujours l’autre tâche (i != j) u while(X){A}: repète A tant que X est vrai F while(X): attend tant que X est vrai

Chap. 728 Idée de l’algorithme 1 n Les threads se donnent mutuellement le tour u T0  T1  T0  T1… n Réalise l’exclusion mutuelle, mais viole l’exigence du déroulement: u Une CritSect pourra être donnée à des threads qui n’en ont pas besoin u P.ex. après T0, T1 pourrait n’avoir pas besoin d’entrer

Chap. 729 Algorithme 1: threads se donnent mutuellement le tour n La variable partagée tour est initialisée à 0 ou 1 n La CritSect de Ti est exécutée ssi tour = i n Ti est actif à attendre si Tj est dans CritSect. n Fonctionne pour l’exclusion mutuelle! n Mais exigence du déroulement pas satisfaite car l’exécution des CritSect doit strictement alterner Thread Ti: while(true){ while(tour!=i); CritSect tour = j; nonCritSect } T0  T1  T0  T1… même si l’un des deux n’est pas intéressé du tout Rien faire

Chap. 730 Thread T0: While(true){ while(tour!=0); CritSect tour = 1; nonCritSect } Thread T1: While(true){ while(tour!=1); CritSect tour = 0; nonCritSect } Algorithme 1 vue globale Initialisation de tour à 0 ou 1 Rien faire

Chap. 731 Exemple: supposez que tour=0 au début Thread T0: while(tour!=0); // premier à entrer CritSect tour = 1; nonCritSect while(tour!=0); // entre quand T1 finit CritSect tour = 1; nonCritSect etc... Thread T1: while(tour!=1); // entre quand T0 finit CritSect tour = 0; nonCritSect while(tour!=1); // entre quand T0 finit CritSect tour = 0; nonCritSect etc...

Chap. 732 Généralisation à n threads n Chaque fois, avant qu’un thread puisse rentrer dans la section critique, il lui faut attendre que tous les autres aient eu cette chance! u En claire contradiction avec l’exigence de déroulement F Supposez le cas de threads, dont seulement quelques uns sont actifs

Algorithme 2 n L’algorithme 2 prend en compte la critique à l’algorithme 1: u Donne la CritSect seulement aux threads qui la veulent n Cependant on ne peut pas permettre à un processus de se redonner systématiquement la CritSec  famine u Faut que chaque processus qui veut entrer donne une chance à des autres avant d’y entrer Chap. 733

Chap. 734 Algorithme 2 ou l’excès de courtoisie... n Une variable Booléenne par Thread: veut[0] et veut[1] n Ti signale qu’il désire exécuter sa CritSect par: veut[i] =vrai n Mais il n’entre pas si l’autre est aussi intéressé! n Exclusion mutuelle ok n Déroulement pas satisfait: n Considérez la séquence: u T0: veut[0] = vrai u T1: veut[1] = vrai F Chaque thread attendra indéfiniment pour exécuter sa CritSect: interblocage Thread Ti: while(true){ veut[i] = vrai; while(veut[j]); CritSect veut[i] = faux; nonCritSect } rien faire

Chap. 735 Thread T0: while(true){ veut[0] = vrai; while(veut[1]); CritSect veut[0] = faux; nonCritSect } Thread T1: while(true){ veut[1] = vrai; while(veut[0]); CritSect veut[1] = faux; nonCritSect } Algorithme 2 vue globale T0: veut[0] = vrai T1: veut[1] = vrai interblocage! Après vous, monsieur

Chap. 736 Algorithme 3 (dit de Peterson) : bon! combine les deux idées: veut[i]=intention d’entrer; tour=à qui le tour n Initialisation: u veut[0] = veut[1] = faux u tour = i ou j n Désir d’exécuter CritSect est indiqué par veut[i] = vrai n veut[i] = faux à la sortie Thread Ti: while(true){ veut[i] = vrai; // je veux entrer tour = j; // je donne une chance à l’autre while (veut[j] && tour==j); CritSect veut[i] = faux; nonCritSect }

Chap. 737 Entrer ou attendre? n Thread Ti attend si: u L’autre veut entrer est c’est le tour à l’autre  veut[j]==vrai et tour==j n Un thread Ti peut entrer si: u L’autre ne veut pas entrer ou c’est la chance à lui F veut[j]==faux ou tour==i Utiliser la logique Booléenne pour contrôler

Chap. 738 Thread T0: while(true){ veut[0] = vrai; // T0 veut entrer tour = 1; // T0 donne une chance à T1 while (veut[1]&&tour=1); CritSect veut[0] = faux; // T0 ne veut plus entrer nonCritSect } Thread T1: while(true){ veut[1] = vrai; // T1 veut entrer tour = 0; // T1 donne une chance à 0 while (veut[0]&&tour=0); CritSect veut[1] = faux; // T1 ne veut plus entrer nonCritSect } Algorithme de Peterson vue globale

Initialisations possibles n Afin qu’un premier processus puisse entrer dans CritSec, il faut que le test veut[j]==faux ou tour==i soit vrai la première fois pour un des deux processus. Voici une possibilité: veut[0]=veut[1]=faux //initialisation Maintenant, si T1 ne fait rien, veut[1] reste faux et T0 peut entrer Exercice: Étudier les autres possibilités pour le début. Chap. 7 39

Chap. 740 Scénario pour le changement de contrôle Thread T0: … CritSect veut[0] = faux; // T0 ne veut plus entrer … Thread T1: … veut[1] = vrai; // T1 veut entrer tour = 0; // T1 donne une chance à T0 while (veut[0]&&tour=0) ; //test faux, entre (F&&V) … T1 donne une chance à T0 mais T0 a dit qu’il ne veut pas entrer. T1 entre donc dans CritSect

Chap. 741 Autre scénario de changem. de contrôle Thread T0: CritSect veut[0] = faux; // T0 ne veut plus entrer nonCritSect veut[0] = vrai; // T0 veut entrer tour = 1; // T0 donne une chance à T1 while (veut[1]==vrai&& tour=1) ; // test vrai, n’entre pas (V&&V) Thread T1: veut[1] = vrai; // T1 veut entrer tour = 0; // T1 donne une chance à T0 // mais T0 annule cette action while (veut[0]&&tour=0) ; //test faux, entre (V&&F) T0 veut rentrer mais est obligé à donner une chance à T1, qui entre

Chap. 742 Mais avec un petit décalage, c’est encore T0! Thread T0: CritSect veut[0] = faux; // 0 ne veut plus entrer nonCritSect veut[0] = vrai; // 0 veut entrer tour = 1; // 0 donne une chance à 1 // mais T1 annule cette action while (veut[1] && tour=1) ; // test faux, entre (V&&F) Thread T1: veut[1] = vrai; // 1 veut entrer tour = 0; // 1 donne une chance à 0 while (veut[0]&&tour=0); // test vrai, n’entre pas Si T0 et T1 tentent simultanément d’entrer dans CritSect, seule une valeur pour tour survivra: non-déterminisme (on ne sait pas qui gagnera), mais l’exclusion fonctionne

Chap. 743 N’oblige pas une tâche d ’ attendre pour d’autres qui pourraient ne pas avoir besoin de la CritSect Supposons que T0 soit le seul à avoir besoin de la CritSect, ou que T1 soit lent à agir: T0 peut rentrer de suite ( veut[1]==faux la dernière fois que T1 est sorti) veut[0] = vrai // prend l’initiative tour = 1 // donne une chance à l’autre while veut[1] && tour=1 // veut[1]=faux, test faux, entre CritSect veut[0] = faux // donne une chance à l’autre Cette propriété est désirable, mais peut causer famine pour T1 s’il est lent (condition de course, race condition)

Hypothèse de fond n Dans des ordis avec plusieurs UCTs, il est nécessaire de supposer que seulement une UCT à la fois puisse exécuter les affectations aux variables veut et tour, ainsi que le test u Pendant qu’un thread ou processus fait accès à une adresse de mémoire, aucun autre ne peut faire accès à la même adresse en même temps Chap. 744

Chap. 745 Algorithme 3: preuve de validité (pas matière d’examen, seulement pour les intéressés…) n Exclusion mutuelle est assurée car: u T0 et T1 sont tous deux dans CritSect seulement si tour est simultanément égal à 0 et 1 (impossible) n Démontrons que déroulement est satisfaits: u Ti ne peut pas entrer dans CritSect seulement si en attente dans la boucle while avec condition: veut[j] == vrai et tour = j. u Si Tj ne veut pas entrer dans CritSect alors veut[j] = faux et Ti peut entrer dans CritSect

Chap. 746 Algorithme 3: preuve de validité (cont.) u Si Tj a effectué veut[j]=vrai et se trouve dans le while, alors tour==i ou tour==j u Si F tour==i, alors Ti entre dans CritSect. F tour==j alors Tj entre dans CritSect mais il fera veut[j] =faux à la sortie: permettant à Ti d’entrer CritSect u mais si Tj a le temps de faire veut[j]=true, il devra aussi faire tour=i u Puisque Ti ne peut modifier tour lorsque dans le while, Ti entrera CritSect après au plus une entrée dans CritSect par Tj (attente limitée)

Différence importante n Qelle est la différence importante entre Algo 1 et 3? u Avec l’Algo 1, tous les processus (interessés ou non) doivent entrer et sortir de leur SC en tour F Violation de l’exigence de déroulement u Avec l’Algo 3, les procs qui ne sont pas intéressés laissent veut = faux et sont libres de faire autres choses Chap. 747

Exemple d’algorithme fautif Thread Ti: while (true) { veut[i] = vrai; // je veux entrer tour = j; // je donne une chance à l’autre do while (veut[i] && tour==j); SC veut[i] = faux; SR } n Cette solution implémente correctement la SC u Un seul proc à la fois peut entrer n Mais elle viole le déroulement u veut[i] = faux n’affecte pas Tj car Tj ne teste pas veut[i] u Tj doit attendre que Ti fasse tour=j après qu’il a fait tour=i, ce qui pourrait ne jamais se vérifier Chap. 748

Chap. 749 A propos de l’échec des threads n Si une solution satisfait les exigences d’ExclMutuelle et déroulement, elle procure une robustesse face à l’échec d’un thread dans sa nonCritSect u un thread qui échoue dans sa nonCritSect est comme un thread qui ne demande jamais d’entrer... n Par contre, situation difficile si un thread échoue dans la CritSect u un thread Ti qui échoue dans sa CritSect n’envoie pas de signal aux autres threads: pour eux Ti est encore dans sa CritSect... u solution: temporisation. Un thread qui a la SC après un certain temps est interrompu par le SE

Chap. 750 Extension à >2 threads n L ’algorithme de Peterson peut être généralisé au cas de >2 threads u n Cependant, dans ce cas il y a des algorithmes plus élégants, comme l’algorithme du boulanger, basée sur l’idée de ‘prendre un numéro au comptoir’... u Pas le temps d’en parler …

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

Chap. 752 Critique des solutions par logiciel n Difficiles à programmer! Et à comprendre! u Les solutions que nous verrons dorénavant sont toutes basées sur l’existence d’instructions spécialisées, qui facilitent le travail. n Les threads qui requièrent l’entrée dans leur CritSect sont actifs à attendre-busy waiting; consommant ainsi du temps de processeur u Situation de scrutation u Pour de longues sections critiques, il serait préférable de bloquer les threads qui doivent attendre... F Et de les interrompre quand ils peuvent entrer Rappel: scrutation ou interruption

Solutions par matériel Chap. 753

Chap. 754 Solutions matérielles: désactivation des interruptions n Si plusieurs UCT: exclusion mutuelle n’est pas préservée u Donc pas bon en général Thread Pi: while(true){ désactiver interrupt CritSect rétablir interrupt nonCritSect }

Chap. 755 Solutions matérielles: instructions machine spécialisées n Normal: pendant qu’un thread ou processus fait accès à une adresse de mémoire, aucun autre ne peut faire accès à la même adresse en même temps n Extension: instructions machine exécutant plusieurs actions (ex: lecture et écriture) sur la même case de mémoire de manière atomique n Une instruction atomique ne peut être exécutée que par un thread à la fois (même en présence de plusieurs processeurs)

Chap. 756 L’instruction test-and-set n Une version C de test- and-set: n Un algorithme utilisant testset pour Exclusion Mutuelle: n Variable partagée b est initialisée à 0 n Le 1er Pi qui met b à 1 entre dans CritSect n Les autres trouvent b à 1, n’entrent pas bool testset(int& i) { if (i==0) { i=1; return true; } else { return false; } Tâche Pi: while testset(b)==false ; CritSect //entre quand vrai instructions critiques... b=0; //sortie de CS nonCritSect Instruction atomique!

Chap. 757 Quand un proc Pi cherche d’entrer: Si la SC est occupée, i=1, testset(b)=faux et Pi reste en attente Si la SC est libre, i=0, il est tout de suite mis à 1 mais testset(b)=vrai et Pi peut entrer

Chap. 758 L’instruction test-and-set (cont.) n Exclusion mutuelle est assurée: si Ti entre dans CritSect, l’autre Tj est actif à attendre n Problème: utilise encore actif à attendre n Peut procurer facilement l’exclusion mutuelle mais nécessite algorithmes plus complexes pour satisfaire les autres exigences du problème de la section critique n Lorsque Ti sort de CritSect, la sélection du Tj qui entrera dans CritSect est arbitraire: pas de limite sur l’attente: possibilité de famine

Chap. 759 Instruction ‘Échange’ (Swap) n Certains UCTs (ex: Pentium) offrent une instruction xchg(a,b) qui interchange le contenue de a et b de manière atomique. n Mais xchg(a,b) souffre des même problèmes que test-and-set

Chap. 760 Utilisation de xchg pour exclusion mutuelle (Stallings) n Variable partagée b est initialisée à 0 n Chaque Ti possède une variable locale k n Le Ti pouvant entrer dans CritSect est celui qui trouve b=0 n Ce Ti exclut tous les autres en assignant b à 1 u Quand CritSect est occupée, k et b seront 1 pour un autre thread qui cherche à entrer u Mais k est 0 pour le thread qui est dans la CritSect Thread Ti: while(true){ k = 1 while k!=0 xchg(k,b); CritSect xchg(k,b); nonCritSect } usage: atomique

Sémaphores avec attente occupée Chap. 761

Chap. 762 Solutions basées sur des instructions fournies par le SE (appels du système) n Les solutions vues jusqu’à présent sont difficiles à programmer n On voudrait aussi qu`il soit plus facile d’éviter des erreurs communes, comme interblocages, famine, etc. u Besoin d’instruction à 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)

Chap. 763 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 acquire(S) u release(S) n Il est partagé entre tous les threads qui s`intéressent à la même CritSect n Les sémaphores seront présentés en deux étapes: u sémaphores qui sont actifs à attendre F Scrutation u sémaphores qui utilisent interruptions et files d ’attente

Chap. 764 Spinlocks d’Unix: Sémaphores occupés à attendre (busy waiting) n La façon la plus simple d’implanter les sémaphores. n Utiles pour des situations où l’attente est brève, ou il y a beaucoup d’UCTs n S est un entier initialisé à une valeur positive, afin qu’un premier thread puisse entrer dans la CritSect n Quand S>0, jusqu’à S threads peuvent entrer n S ne peut jamais être négatif acquire(S): while S==0 ; S--; release(S): S++; Attend si no. de threads qui peuvent entrer = 0 Augmente de 1 le no des threads qui peuvent entrer

Chap. 765 Atomicité Acquire : La séquence test- décrément est atomique, mais pas la boucle! Release est atomique. Rappel: les sections atomiques ne peuvent pas être exécutées simultanément par différent threads (ceci peut être obtenu en utilisant un des mécanismes précédents) S == 0 atomique S - - F V CritSect IMPORTANT

Chap. 766 Atomicité S == 0 atomique S - - F V S++ La boucle peut être interrompue pour permettre à un autre thread d’interrompre l’attente quand l’autre thread sort de la CritSect interruptible autre thr. CritSect (Autre thread)

Chap. 767 Thread T1: while(true){ acquire(S); CritSect release(S); nonCritSect } Thread T2: while(true){ acquire(S); CritSect release(S); nonCritSect } Semaphores: vue globale Initialise S à > =1 Peut être facilement généralisé à plus. threads

Chap. 768 Utilisation des sémaphores pour sections critiques n Initialiser S à 1 n Alors 1 seul thread peut être dans sa CritSect n Pour permettre à k threads d’exécuter CritSect, initialiser S à k Thread Ti: while(true){ acquire(S); CritSect release(S); nonCritSect }

Chap. 769 Utilisation des sémaphores pour mettre des threads en seq. n On a 2 threads n P1 dans le premier thread doit être exécuté avant P2 dans le deuxième n Définissons deux sémaphores S et T n Initialisons S à 1, T à 0 P1 P2 acquire(S) P1; release(T) acquire(T); P2

Famine possible avec les sémaphores spinlocks n Un thread peut n’arriver jamais à exécuter car il ne teste jamais le sémaphore au bon moment Chap. 770

Chap. 771 Interblocage avec les sémaphores n Interblocage: Supposons S et Q initialisés à 1 u Ils seront 0 au deuxième acquire u Aucun des deux ne peut avancer T0 T1 acquire(S) acquire(Q) acquire(Q) acquire(S)

Chap. 772 Sémaphores: observations n Quand S >= 0: u Le nombre de threads qui peuvent exécuter acquire(S) sans devenir bloqués = S F S threads peuvent entrer dans la CritSect F Puissance par rapport aux mécanismes précédents F Dans les solutions où S peut être > 1 il faudra avoir un 2ème sém. pour les faire entrer un à la fois (excl. mutuelle) n Quand S devient > 1, le thread qui entre le premier dans la CritSect est le premier à tester S (choix aléatoire) u Famine possible F Ceci ne sera plus vrai dans la solution suivante acquire(S): while S==0 ; S--;

Chap. 773 Comment éviter l’attente occupée et le choix aléatoire dans les sémaphores n Quand un thread doit attendre qu’un sémaphore devienne plus grand que 0, il est mis dans une file d’attente de threads 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 threads entrent dans leur CritSect n acquire et release sont des appels au système comme les appels à des opérations d’E/S n Il y a une file d ’attente pour chaque sémaphore comme il y a une file d’attente pour chaque unité d’E/S

Sémaphores avec files d’attente Chap. 774

Chap. 775 Sémaphores avec file d’attente n Un sémaphore S devient une structure de données: u S.value: Une valeur: nombre de processus pouvant entrer u S.list Une liste d’attente acquire(S): bloque thread qui effectue l’opération et l’ajoute à la liste S.list release(S) enlève (selon une politique juste, ex: PAPS/FIFO) un thread de S.list et le place sur la liste des threads prêts/ready. un tel sémaphore peut être associé à une liste d’attente comme un disque, une imprimante, etc.

Chap. 776 Implementation (les boîtes représentent des séquences atomiques) acquire(S):S.value --; si S.value < 0 { // CritSect occupée ajouter ce thread à S.list; block // thread mis en état attente (wait) } si S.value ≥ 0, continuer le thread release(S): S.value ++; si S.value  0 { // des threads attendent enlever thread P from S.list; wakeup(P) // thread choisi devient prêt } S.value doit être initialisé à une valeur non-négative (dépendant de l’application, v. exemples)

Chap. 777 Figure montrant la relation entre le contenu de la file et la valeur de S (la séquence montrée n’est pas contigüe) S > 0: n threads peuvent entrer S  0: aucun thread ne peut entrer et le nombre de threads qui attendent sur S est = |S| Stallings

Chap. 778 acquire et release contiennent elles mêmes des CritSect! n Les opérations acquire et release doivent être exécutées de manière atomique (un seul thr. à la fois) n Pour ça, nous devons utiliser un des mécanismes vus avant u instructions spéciales: test-and-set n L’attente occupée dans ce cas ne sera pas trop onéreuse car acquire et release sont courts

Exercice n Avec cette solution, on peut effectivement éviter la famine! n Expliquez pourquoi et comment Chap. 779

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

Application: Tampon borné ou producteur-consommateur Chap. 781

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

Chap. 783 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

Chap. 784 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

Chap. 785 Pb de sync entre threads pour le tampon borné n Étant donné que le prod et le consommateur sont des threads 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

Chap. 786 Sémaphores: rappel n Soit S un sémaphore sur une CritSect u il est associé à une file d ’attente u S > 0 : S threads peuvent entrer dans CritSect u S = 0 : aucun thread ne peut entrer, aucun thread en attente u S < 0 : |S| thread dans file d ’attente n acquire(S): S - - u si avant S > 0, ce thread peut entrer dans CritSect u si avant S <= 0, ce thread est mis dans file d ’attente u release(S): S++ u si avant S < 0, il y avait des threads en attente, et un thread est réveillé u si avant S >= 0, rien (mais un proc de plus pourra entrer) u Atomicité de ces ops

Pensez à un petit entrepôt de caisses d’un produit n Ceux qui veulent y apporter une caisse, doivent avant tout savoir s’il y a de l’espace u Un sémaphore E dit combien d’espace dispo: F Producteur peut entrer si et seulement si il y en a n Ceux qui veulent en retirer des caisses, doivent avant tout savoir s’il y en a à retirer u Un sémaphore F qui dit combien de caisses disponibles: F Consommateur peut entrer si et seulement si il y en a n Pour éviter la confusion, une seule personne peut y travailler à un moment donné u Un sémaphore M dit s’il y a quelqu’un dans l’entrepôt F Occupé ou libre Chap. 787

Chap. 788 Autrement dit … n Un sémaphore E pour synchroniser producteur et consommateur sur le nombre d’espaces libres n Un sémaphore F pour synchroniser producteur et consommateur sur le nombre d’éléments consommables dans le tampon n Un sémaphore M pour exclusion mutuelle sur l’accès au tampon u Les sémaphores suivants ne font pas l’ExMut

Chap. 789 Solution de P/C: tampon circulaire fini de dimension k Initialization: M.count=1; //excl. mut. F.count=0; //esp. pleins E.count=k; //esp. vides Producteur: while(true){ produce v; acquire(E); acquire(M); ajouter(v); release(M); release(F); } Consommateur: while(true) acquire(F); acquire(M); retirer(); release(M); release(E); consume(w); } Sections Critiques ajouter(v): b[in]=v; In ++ mod k; retirer(): w=b[out]; Out ++ mod k; return w;

Chap. 790 Points intéressants à étudier n Dégâts possibles en inter changeant les instructions sur les sémaphores u ou en changeant leur initialisation n Généralisation au cas de plus. prods et cons

Chap. 791 Concepts importants de cette partie du Chap 7 n Le problème de la section critique n L’entrelacement et l’atomicité n Problèmes de famine et interblocage n Solutions logiciel n Instructions matériel n Sémaphores occupés ou avec files n Fonctionnement des différentes solutions n L’exemple du tampon borné n Par rapport au manuel: ce que nous n’avons pas vu en classe vous le verrez au lab

Chap. 792 Glossaire: atomicité n Atomicité, non-interruptibilité: u Le mot atomique a été utilisé dans son sens original grec: a- tomos = non-divisible F Faut pas se faire dérouter par le fait que les atomes dans la physique moderne sont divisibles en électrons, protons, etc. … u La définition précise d’atomicité, non-déterminisme etc. est un peu compliquée, et il y en a aussi des différentes… (faites une recherche Web sur ces mot clé) u Ce que nous discutons dans ce cours est un concept intuitif: une séquence d’ops est atomique si elle est exécutée toujours du début à la fin sans aucune interruption ni autres séquences en parallèle

Chap. 793 Non-déterminisme et conditions de course n Non-déterminisme: une situation dans laquelle il y a plusieurs séquences d’opérations possibles à un certain moment, même avec les mêmes données. u Ces différentes séquences peuvent conduire à des résultats différents n Conditions de course: Les situations dans lesquelles des activités exécutées en parallèle sont ‘en course’ les unes contre les autres pour l`accès à des ressources (variables partagées, etc.), sont appelées ‘conditions de course ’ u L’ordre des accès détermine le résultat

Chap. 794 Thread, processus n Les termes thread, process, sont presque équivalents dans ce contexte n Tout ce que nous avons dit au sujet de threads concurrent est aussi valable pour processus concurrents

Chap. 795 Différents noms pour acquire, release n Acquire, release ont eté appelés des noms différents n Leur inventeur (Dijkstra) les appelait P, V (provenant de mots en Hollandais …) n D’autres auteurs les appellent wait, signal n Etc.

Chap. 796 Sémaphores binaires n Dans les sémaphores binaires, la variable ne peut être que 0 ou 1 n P.ex. le sémaphore S dans le producteur- consommateur est binaire n On a prouvé en théorie que tout pb de synchro peut être résolu utilisant seulement des sémaphores binaires, v. manuel

Chap. 797 Difficulté des problèmes de synchronisation n Les problèmes et solutions qui se trouvent dans l’étude du parallélisme et de la répartition sont entre les plus complexes de l’informatique n Car les programmes parallèles ont un comportement mutuel imprévisible dans le temps n Beaucoup de concepts complexes de math, physique etc. peuvent entrer en considération n Heureusement, les langages de programmation comme Java nous cachent cette complexité n Mais pas complètement … les systèmes répartis sont sujets à des pannes imprévisibles u dues à des conditions de temporisation non prévues

Parallélisme dans la programmation fonctionnelle n Dans la programmation fonctionnelle, le parallélisme vient naturel sans besoin d’artifices: u y = g(f(x,y), h(z)) F Pour calculer y, la fonction g lance en parallèle les fonctions f et h qui n’ont pas besoin de communiquer l’une avec l’autre n Cependant la programmation purement fonctionnelle est peu utilisée pour des raisons pratiques Chap. 798