GEF 435 Principes des systèmes d’exploitation Communication Interprocessus (Tanenbaum 2.3)

Revue Quels sont nos trois choix pour implémenter les threads? Donner des avantages d’implémenter les threads dans l’espace utilisateur. Three choices: User space, kernel, hybrid Advantages: Each process can have its own scheduling algorithm Fast as less TRAPS to the kernel have to be made Can be implemented on an OS without its knowledge Easily scaled as the run-time system can allocate memory for the threads

Synopsis Synopsis de la communication interprocessus Concurrence critique (Race Conditions) Régions critiques Exclusion mutuelle Méthodes d’exclusion mutuelle

Synopsis de la CIP Les processus doivent communiquer ensemble souvent pour être capable d’achever certaines tâches Comment est-ce que les processus envoient de l’information entre eux? Comment est-ce que l’on empêche les processus d’interférer entre eux? Comment fait-on attendre un processus pour que d’autres finissent leurs activités? (ie: Processus A produit des données utilisées par le Processus B) Note that the second two concerns listed here apply equally well to threads as well, but we’ll generalize to processes. The first concern isn’t as big of a problem as threads share memory space. We don’t want to use interrupts to solve this. We’ll look at how messages are passed later on...but these are the things we want to solve during the section on IPC.

Concurrence critique S’applique aux processus qui travaillent ensemble mais qui partagent de la mémoire commune pour la lecture et écriture Mémoire principale (RAM) Fichiers partagés Registres d’unité périphérique This potential to share a spot of main memory contradicts our original discussion of processes, but they’ll just have to accept that it’s possible depending on the implementation of the OS

Concurrence critique Exemple: un spouleur d’impression Quand un processus veut imprimer, il place le nom du fichier dans une case du répertoire de l’imprimante Chaque case contient un nom de fichier Deux variables partagées: out pointe au prochain fichier à être imprimé in pointe à la prochaine case Un démon vérifie périodiquement si il y a un fichier à imprimer Y a t-il un problème avec ça? Note that the user processes are responsible for updating in, the next free slot Ask them to think about a two process system and see if they can think of any potential problems with such a system.

Concurrence critique Exemple du spouleur d’impression Un changement de processus à un moment inopportun cause le processus B à perdre sa job d’impression Process A Process B freeSlot = in; writeName(freeSlot); in = freeSlot+1; doMoreStuff();

Concurrence critique Une Concurrence critique est une situation où deux processus ou plus essaient de partager des données et le résultat dépend de l’ordre dans lequel chaque processus exécute Donc la place dans le code où une condition de concurrence critique peut arriver est d’intérêt particulier et s’appelle une Région critique (ou section critique) Note that this is really for the case where you expected the result to be determinable, but this is more random. Therefore, it doesn’t count as a race condition if you expect the behavior to be non-deterministic.

Régions critiques Idéalement, nous essayons de ne pas avoir des régions dans le code où la concurrence critique peut arriver, mais cela n’est pas toujours possible Les programmes doivent être arrangés ou dessinés de tel façon à ce qu’aucun groupe de processus n’opère dans leurs région critique (commune) en même temps Les régions critiques doivent être mutuellement exclusive I say (related) to indicate that it’s OK for processes A and B to be in their critical sections if the shared memory which they are accessing is not related, ie: A might have a conflict with Process C and B with D.

Exclusion mutuelle C’est évident que les régions critiques doivent opérer en exclusion mutuelle mais ce n’est pas une définition suffisante pour nos besoins. La solution pour prévenir la concurrence critique doit rencontrer ces requis: 1) Aucune paire de processus ne doit être dans leurs régions critique en même temps 2) Aucune supposition ne peut être fait à propos de la vitesse ou du nombre de CPU 3) Un processus qui n’opère pas dans sa région critique ne doit pas bloquer un autre processus 4) Un processus ne devrait pas avoir à attendre indéfiniment pour entrer dans sa région critique

Une représentation graphique de notre requis pour l’exclusion mutuelle Here two processes, A and B, share a critical region. Meets our requirements: It shows how they’re not in at the same time (no assumptions made about speed/num CPUs) A’s entering of the critical region did not immediately block B B got into the critical region as soon as A was done with it (didn’t wait forever). Une représentation graphique de notre requis pour l’exclusion mutuelle

Méthodes pour implémenter l’exclusion mutuelle Trois solution potentielles : Désactiver les interruptions Utiliser des variables verrous Alternance stricte

Méthodes pour l’exclusion mutuelle Désactiver les interruptions: Chaque processus désactive les interruptions quand ils entre dans leur région critique. Aucun changement de contexte ne peut arriver Problème: Si le thread utilisateur barre ou entre dans une boucle infinis le SE barre ou plante Problème: Que ce passe-t-il avec des CPU multiples? Problème: Si la région critique est large, qu’est ce qui ce passe si un périphérique a besoin d’attention Solution viable? Non. Note on first problem: is disabling interrupts the kind of power an OS should give the average user program?

Méthodes pour l’exclusion mutuelle Variables verrous: Partage d’une variable verrou (lock) Quand un processus veut entrer dans sa région critique il examine le verrou, si la valeur est 0 il le met à 1 et entre dans la région critique Problème: Cette solution déplace la concurrence critique de place. Un changement de processus à un moment inopportun peut résulter dans les deux processus dans la région critique en même temps Solution viable? Non. Note that people sometimes think that you can simply test the lock variable again to ensure that a context switch didn’t just result in another process changing the lock variable, but this is an infinitely recursive idea.

Méthodes pour l’exclusion mutuelle Alternance stricte Notez que le point-virgule après les instructions while() – crée une mini boucle Vérifier une variable continuellement jusqu’à ce qu’une valeur apparaisse s’appelle de l’attente active (Busy Waiting) Process A Process B Explain that loop structure! Draw it out with turn on the blackboard!

Méthodes pour l’exclusion mutuelle Alternance stricte opère d’après son nom: Chaque processus prend son tour pour entrer dans sa région critique La mini boucle while est utilisée comme verrou pour empêcher l’entrée dans la région critique. Un verrou qui utilise une attente active (busy waiting) s’appelle un spin lock Problème: la 3ème règle est violée – si A exécute plus vite que B, A attend pour entrer dans sa région critique pendant que B exécute du code non critique Solution viable? Non. Mais c’est proche... Put differently: taking turns is not a good idea when one of the processes is much slower than the other. Also: just plain old not practical: Word can’t print until Powerpoint does? What kind of a system is that? Races avoided, but not useful.

Méthodes pour l’exclusion mutuelle Solution de Peterson Note an error in the book that places a semicolon at the end of void enter_region(int process); { Hard to wrap your head around this but it works! Before entering their critical region each process will call enter_region and will call leave_region when they’re done Two conditions to enter: if either the other process isn’t interested OR if the other process has changed the variable turn Means that if the context switches occur such that both are interested it’s ok, as as whoever set turn=process last won’t get in! Should draw this one out and make sure they get it!

Méthodes pour l’exclusion mutuelle Solution de Peterson Région critique est maintenant protégée Solution viable? Oui! Par contre l’attente active est encore requise… une perte de temps du CPU Notez aussi que le processus ne peut pas tricher: si les processus n’appelle pas enter_region et leave_region, la solution ne marchera pas Aussi fonctionne seulement pour deux processus. Algorithme du boulanger est utilisé dans ce cas

Méthodes pour l’exclusion mutuelle De l’aide du matériel: TSL TSL veut dire instruction Test and Set Lock Plusieurs ordinateurs supportent cette instruction ou une instruction semblable Comment est-ce utilisé? TSL RX,LOCK Lis le contenue de la variable en mémoire, LOCK dans le registre RX et entrepose une valeur non zéro dans la variable LOCK Les actions de lire le mot LOCK et d’entreposer la valeur non zéro sont indivisibles c’est garantie! Processeurs multiples aussi

Méthodes pour l’exclusion mutuelle Comment utiliser l’instruction TSL? Comme la solution de Peterson, on entoure la région critique avec les appels enter_region et leave_region Solution viable? Oui! (Avec attente active...) Note that there’s no risk in the instruction MOVE LOCK,#0 as the test/set operation is indivisible. The hardware prevents the race condition Ask them to consider multi-processor systems. Will this function work? Only if the CPU locks the memory bus before the TSL instruction

Quiz Time! Questions? What are our four conditions for mutual exclusion? The processes must not be in their critical regions at the same time No assumptions may be made about speed/number of CPUs A process should not be prevented from entering its critical region by a process not in its critical region No process should wait forever to enter its critical region Why is strict alternation a bad idea (even if it prevents race conditions) If one process is faster than the other you violate condition 3