Synchronisation de Processus (ou de threads, fils ou tâches) Chapitre 7 http://w3.uqo.ca/luigi/ Chap. 7

Le problème Chap. 7

Problèmes avec concurrence = parallélisme Les threads concurrents doivent parfois partager données (fichiers ou mémoire commune) et ressources On parle donc de threads coopérants 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). Un programme pourra donner des résultats différents et parfois indésirables de fois en fois Chap. 7

Exemple 1 Deux threads exécutent cette même procédure et partagent la même base de données Ils peuvent être interrompus n’importe où Le résultat de l ’exécution concurrente de P1 et P2 dépend de l`ordre de leur entrelacement Souvent bon, parfois mauvais 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. 7

Vue globale d’un «mauvais» entrelacement P1 P2 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 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é Chap. 7

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

Exemple 2 Cas pratique: Deux threads qui mettent à jour un seul compteur d’accès à une page web Exécuter en parallèle avec lui-même le code suivant: Quel pourrait être le résultat final dans a? b=a b++ a=b Chap. 7

Deux opérations en parallèle. var a partagée entre thread Deux opérations en parallèle var a partagée entre thread var b est privée à chaque thread b=a b++ a=b P1 P2 interruption Supposons que a soit 0 au début P1 travaille sur son propre b donc le résultat final sera a=1. Mais il pourrait y avoir des cas où le résultat sera correct! Chap. 7

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

Asynchronie des threads 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 Peuvent être différents à chaque exécution du programme Dont le non-déterminisme Chap. 7

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

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

Section Critique Partie d’un processus dont l’exécution ne doit pas entrelacer avec autres processus Indivisibilité de la section critique 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 La section critique doit être verrouillée afin de devenir indivisible Chap. 7

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

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

Section critique verrouillée: contrôler que ceci évite le pb 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é indivisible Chap. 7

Le « mauvais » entrelacement n’est pas possible M. Leblanc demande une réservation d’avion Base de données dit que fauteuil 30A est occupé 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é Chap. 7

Le problème de la section critique 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) 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) L’exécution des sections critiques doit être mutuellement exclusive et indivisible: à tout instant, un seul thread peut exécuter une CritSect pour une donnée (même lorsqu’il y a plusieurs UCT) Ceci peut être obtenu en plaçant des instructions spéciales au début et à la fin de la CritSect Implantation du cadenas Chap. 7

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

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

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

Exigences pour solutions valides (*) Exclusion Mutuelle En tout moment, au plus un thread peut être dans une CritSect Déroulement Une CritSect ne sera donnée qu’à un thread qui attend d’y entrer 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) Attente bornée Un thread qui attend d’entrer dans une CritSect pourra enfin y entrer (pas de famine) = aucun thread ne peut être exclu à jamais de la CritSect à cause d’autres threads qui la monopolisent Notez la différence entre interblocage et famine Chap. 7

Trois types de solutions Solutions par logiciel des algorithmes qui n’utilisent pas d`instruction spéciales Solutions fournies par le matériel s’appuient sur l’existence de certaines instructions (du processeur) spéciales Solutions fournies pas le SE procure certains appels du système au programmeur Toutes les solutions se basent sur l’indivisibilité 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. Plus en général, toutes les solutions se basent sur l’existence d’instructions indivisibles, qui fonctionnent comme Sections Critiques de base Chap. 7

Solutions par logiciel pur Chap. 7

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

Un groupe d’étudiants collabore sur un devoir Solution 1: Ils se passent le devoir dans un ordre fixe: Marc, Ahmed, Marie, Marc, Ahmed, Marie … Solution 2: Semblable, mais donner la chance seulement à ceux qui veulent travailler Chap. 7

Un groupe d’étudiants collabore sur un devoir Solution 1: Un étudiant passe la copie au prochain dans un ordre fixe: Marc, Ahmed, Marie, Marc, Ahmed, Marie … Solution 2: Semblable, mais donner la chance seulement à ceux qui veulent travailler Solution 3: Combiner les idées des solutions précédentes Chap. 7

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

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

Algorithme 1: threads se donnent mutuellement le tour La variable partagée tour est initialisée à 0 ou 1 La CritSect de Ti est exécutée ssi tour = i Ti est actif à attendre si Tj est dans CritSect. Fonctionne pour l’exclusion mutuelle! Mais exigence du déroulement pas satisfaite car l’exécution des CritSect doit strictement alterner Rien faire 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 Chap. 7

Algorithme 1 vue globale Initialisation de tour à 0 ou 1 Rien faire 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 Chap. 7

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

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

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

Algorithme 2 ou l’excès de courtoisie... Une variable Booléenne par Thread: veut[0] et veut[1] Ti signale qu’il désire exécuter sa CritSect par: veut[i] =vrai Mais il n’entre pas si l’autre est aussi intéressé! Exclusion mutuelle ok Déroulement pas satisfait: Considérez la séquence: T0: veut[0] = vrai T1: veut[1] = vrai 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. 7

Algorithme 2 vue globale Après vous, monsieur Après vous, monsieur 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! Chap. 7

Algorithme 3 (dit de Peterson): bon Algorithme 3 (dit de Peterson): bon! combine les deux idées: veut[i]=intention d’entrer; tour=à qui le tour Initialisation: veut[0] = veut[1] = faux tour = i ou j Désir d’exécuter CritSect est indiqué par veut[i] = vrai 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. 7

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

Algorithme de Peterson vue globale 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 Chap. 7

Un début – étudier aussi les autres possibilités Thread T0: while(true){ veut[0] = vrai; // T0 veut entrer tour = 1; // T0 donne une chance à T1 while (veut[1]&&tour==1); //tour=0, test est faux, T0 entre CritSect … Thread T1: while(true){ veut[1] = vrai; // T1 veut entrer tour = 0; // T1 donne une chance à T0 while (veut[0]&&tour==0); //test est vrai,T1 attend dans boucle 40 Chap. 7 Chap. 7

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

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

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

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

Hypothèse de fond 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 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. 7

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

Par rapport aux trois conditions On peu prouver que l’algorithme de Peterson satisfait aux trois exigences pour solutions valides mentionnées avant Notamment, un processus qui demande d’entrer entrera ‘la prochaine fois’ Attente bornée V. plus loin dans ces notes Chap. 7

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 } Cette solution implémente correctement la SC Un seul proc à la fois peut entrer Mais elle viole le déroulement veut[i] = faux n’affecte pas Tj car Tj ne teste pas veut[i] 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. 7

Exercice (facile): déterminer si cet algorithme fonctionne Thread Ti: while (true) { veut[i] = vrai; tour = j; do while (veut[j] && tour==j){veut[j]=faux}; CritSect nonCritSect Chap. 7

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

Extension à >2 threads L ’algorithme de Peterson peut être généralisé au cas de >2 threads http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1778&context=cstech 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’... Pas le temps d’en parler … Chap. 7

Une leçon à retenir… 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 Un protocole commun Chap. 7

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

Solutions par matériel Chap. 7

Solutions matérielles: 1) désactivation des interruptions Si plusieurs UCT: exclusion mutuelle n’est pas préservée On ne peut pas désactiver les interruptions sur toutes les UCT en même temps Donc pas bon en général Thread Pi: while(true){ désactiver interrupt CritSect rétablir interrupt nonCritSect } Chap. 7

Solutions matérielles: 2) instructions de machine spécialisées Fait: Accès exclusif à la mémoire pour les UCT Une seule UCT à la fois peut faire accès à la mémoire centrale Donc un seul processus ou thread à la fois Ce fait est déjà utilisé dans les solution précédentes, mais peut aussi être utilisé pour des instructions spécialisées, comme la suivante Chap. 7

Instruction ‘Échange’ (Swap) Plusieurs UCTs (ex: Pentium) offrent une instruction xchg(a,b) qui interchange le contenu de a et b de manière indivisible. L’instruction entière est exécutée dans un seul cycle de mémoire Sans possibilité pour autres processus d’exécuter des autres instructions en même temps Chap. 7

Utilisation de xchg pour exclusion mutuelle (Stallings) Variable partagée b est initialisée à 0 Chaque Ti possède une variable locale ki Un Ti peut entrer dans CritSect s’il trouve b==0 Ce Ti exclut les autres en affectant b=1 Quand CritSect est occupée, kj et b seront 1 pour un autre thread qui cherche à entrer Mais k est 0 pour le thread qui est dans la CritSect usage: Thread Ti: while(true){ ki = 1 while ki==1 xchg(ki,b); CritSect xchg(ki,b); //sortie nonCritSect } Chap. 7

Fonctionnement … b initialisé à 0 Thread T0: while(true){ k0 = 1 while k0==1 xchg(k0,b); // la 2ème fois que k0 est testé il est 0 et donc le test est faux; T0 entre et b==1, k0==0 CritSect xchg(k0,b); // b==0, k0==1 nonCritSect } Thread T1: while(true){ k1 = 1 while k1==1 xchg(k1,b); // k1==1 et b==1 continue à échanger k1 et b // k1==0; T1 entre et b==1, k1==0 T0 ne peut pas entrer car k0==1 CritSect xchg(k1,b); //T0 peut entrer nonCritSect } Chap. 7

Considérations sur Échange Si un thread entre dans CritSect, un autre qui voudrait y entrer est actif à attendre Il boucle en attente de pouvoir exécuter son exch Lorsque un thread sort de CritSect, le prochain thread qui l’a est le premier qui réussit à exécuter une échange: pas de limite sur l’attente pour les processus ‘lents’: possibilité de famine Chap. 7

Exercice Voir ce qui pourrait se passer si b est initialisée à 1 Chap. 7

Sémaphores avec attente occupée Chap. 7

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

Sémaphores Un sémaphore S est un entier qui, sauf pour l'Initialisation, est accessible seulement par ces 2 opérations indivisibles et mutuellement exclusives: acquire(S) release(S) Il est partagé entre tous les threads qui s`intéressent à la même CritSect Les sémaphores seront présentés en deux étapes: sémaphores qui sont actifs à attendre Scrutation sémaphores qui utilisent interruptions et files d ’attente Chap. 7

Spinlocks d’Unix-Linux: Sémaphores occupés à attendre (busy waiting) La façon la plus simple d’implanter les sémaphores. Utiles pour des situations où l’attente est brève, ou il y a beaucoup d’UCTs S est un entier initialisé à une valeur positive, afin qu’un premier thread puisse entrer dans la CritSect Quand S>0, jusqu’à S threads peuvent entrer Quand S=0, aucun ne peut entrer 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. 7

Idée Une salle avec limites de capacité Un gardien à la porte compte les personnes qui entrent, laisse entrer seulement si la salle n’est pas pleine Soustrait 1 d’un compteur quand il laisse entrer quelqu’un Ajoute 1 au compteur quand quelqu'un sort Si on veut seul. 1 personne dans la salle, on initialise le compteur à 1 Chap. 7

Indivisibilité IMPORTANT Acquire: La séquence test-décrément est indivisible mais pas la boucle! Release est indivisible. Rappel: les sections indivisibles 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 indivisible S - - F V CritSect Chap. 7

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

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

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

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

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

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

Sémaphores: observations acquire(S): while S==0 ; S--; Quand S >= 0: Le nombre de threads qui peuvent exécuter acquire(S) sans devenir bloqués = S S threads peuvent entrer dans la CritSect Puissance par rapport aux mécanismes précédents 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) Quand S devient > 1, le premier thread qui entre dans la CritSect est le premier à tester S (choix aléatoire) Famine possible Ceci ne sera plus vrai dans la solution suivante Chap. 7

Comment éviter l’attente occupée et le choix aléatoire dans les sémaphores 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 Les files peuvent être PAPS (FIFO), avec priorités, etc. Le SE contrôle l`ordre dans lequel les threads entrent dans leur CritSect acquire et release sont des appels au système comme les appels à des opérations d’E/S 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 Chap. 7

Sémaphores avec files d’attente Chap. 7

Idée des sémaphore avec liste d’attente Pensez à une salle avec limites d’admission Un gardien est à la porte et compte les personnes qui entrent et sortent Si la salle est pleine: Avec les spinlocks, une personne qui veut entrer est renvoyée et doit revenir plus tard pour voir s’il y a de la place Dans les sémaphores avec liste d’attente, une personne qui veut entrer est mise en attente et réveillée quand il y aura de la place Chap. 7

Sémaphores avec file d’attente Un sémaphore S devient une structure de données: S.value: Une valeur: nombre de processus pouvant entrer S.list Une liste d’attente acquire(S): Si S==0 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. S>0 est un événement qu’un processus doit attendre Chap. 7

Implementation (les boîtes représentent des séquences indivisibles) acquire(S): S.value --; si S.value < 0 { // CritSect occupée, thread doit attendre 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. 7

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

acquire et release contiennent elles mêmes des CritSect! Les opérations acquire et release doivent être exécutées de manière indivisible (un seul thr. à la fois) Pour faire ça, nous devons utiliser un des mécanismes vus avant P.ex. instruction Exchange Avec attente occupée L’attente occupée dans ce cas ne sera pas trop onéreuse car acquire et release sont courts Chap. 7

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

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

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

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

Tampons de communication Prod Prod 1 donn 1 donn 1 donn 1 donn Cons Cons 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. 7

Le tampon borné (bounded buffer) une structure de données fondamentale dans les SE in: 1ère pos. libre b[1] b[0] b[1] b[2] b[3] b[4] b[5] b[6] b[7] b[0] b[7] b[2] ou b[6] b[3] in: 1ère pos. libre out: 1ère pos. pleine b[5] b[4] 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. 7

Pb de sync entre threads pour le tampon borné É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 Les sémaphores peuvent résoudre ce problème Chap. 7

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

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

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

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 ajouter(v): b[in]=v; In ++ mod k; 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); } retirer(): w=b[out]; Out ++ mod k; return w; Sections Critiques Chap. 7

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

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

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

Non-déterminisme et conditions de course 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. Ces différentes séquences peuvent conduire à des résultats différents 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 ’ L’ordre des accès détermine le résultat Chap. 7

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

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

Difficulté des problèmes de synchronisation 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 Car les programmes parallèles ont un comportement mutuel imprévisible dans le temps Beaucoup de concepts complexes de math, physique etc. peuvent entrer en considération Heureusement, les langages de programmation comme Java nous cachent cette complexité Mais pas complètement … les systèmes répartis sont sujets à des pannes imprévisibles dues à des conditions de temporisation non prévues Chap. 7

MATÉRIAUX SUPPLÉMENTAIRES Ch. 6

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

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

Algorithme 3: preuve de validité (cont.) Si Tj a effectué veut[j]=vrai et se trouve dans le while, alors tour==i ou tour==j Si tour==i, alors Ti entre dans CritSect. tour==j alors Tj entre dans CritSect mais il fera veut[j] =faux à la sortie: permettant à Ti d’entrer CritSect mais si Tj a le temps de faire veut[j]=true, il devra aussi faire tour=i 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 bornée) Chap. 7

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

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

Parallélisme dans la programmation fonctionnelle Dans la programmation fonctionnelle, le parallélisme vient naturel sans besoin d’artifices: y = g(f(x,y), h(z)) 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 Cependant la programmation purement fonctionnelle est peu utilisée pour des raisons pratiques Chap. 7