Communication inter-processus

et Interblocage

1
Plan
1 Introduction

2 Communication par signaux

3 Communication par tubes

4 Interblocages

2
Plan
1 Introduction

2 Communication par signaux

3 Communication par tubes

4 Interblocages

3
Introduction

Rôles d’un SE
Gestion des processus

Chaque processus
Est autonome
Vit isolé dans son propre espace mémoire

Trop restrictif
besoin de communication

4
Deux types de besoin de
communication
Données échangées entre processus
Chacun les traite à safaçon
Un seul processus a les données à la fois

Données partagées entre processus

Données communes
Accès et modifications non exclusives

En pratique
Échanges et partages sont utiles pour tout type de
processus
5
Exemples de besoins de
communication
Réservation de billet d’avion
Une base de données commune est partagée par
tous les « guichets »

Terminaison d’un processus

Le processus parent est informé de la terminaison
des processus enfants

Tubes de communications enshell

$ ls | cut − f 2 −d _ | sort −u
Trois processus travaillent de concert
Types de communication

Type simple
l’échange d’un simple élément entre un processus
expéditeur et un processus receveur
Exemples : wait(), waitpid(), kill()

Type complexe
Échange ou partage continue de donné avec
protection et synchronisation
Exemples : tubes de communication, réseau
Gestion de lacommunication

Il faut un protocole de communication

Moyens de communication (données, structures de
données) que les processus peuvent échanger et
accéder
Primitives d’accès et de protection
Mécanismes de synchronisation
Attention aux problèmes standard :
interblocage, famine, etc.
Qui s’en charge
Le systèmed’exploitation
Appels systèmes qui imposent le protocole mais
garantissent certaines propriétés

Le programmeur
Il a une liberté étendue mais a la charge d’assurer
les besoins liés à la communication

En fait un peu des deux

Le programmeur se base sur des appels systèmes et
des protocoles simples pour construire un protocole
plus complexe
Exemple : terminaison des processus
Principe sous Unix
Tout processus qui se termine l’annonce à son
processus parent

Le processus parent peut

Prendre connaissance (wait(), waitpid()) et analyser
la cause de la terminaison
Ignorer totalement l’événement

Processus terminé
Un processus terminé est dans l’état zombi jusqu’à
sa prise en considération par son processus parent
Plan
1 Introduction

2 Communication par signaux

3 Communication par tubes

4 Interblocages

6
Signaux

Forme d’interruption logicielle

Analogie avec les interruptions matérielles
Permet d’expédier à un processus une information
urgente

Comportement asynchrone
Un signal est envoyé
Il sera reçu et traité au moment opportun
Sémantique des signaux
Liste dessignaux
Les signaux sont catalogués, la liste est fixée et
chacun est documenté
$ man 7 signal

Un gestionnaire de signaux par processus

Chaque programme gère toutefois les signaux
comme il veut
La sémantique doit être documentée dans le
programme (man)
Exemples de signaux
SIGINT
Ctrl C génère ce signal dont le comportement par
défaut est d’arrêter le processus

SIGSEV
Une erreur de segmentation provoque l’expédition
de ce signal au processus fautif

kill
La commande shell « kill 9482 » envoie un signal
SIGTERM au processus 9482.
L’appel système kill() permet également d’envoyer
des signaux.
Action possibles pour un signal
Pour chaque catégorie de signal, un processus peut
Accepter le comportement par défaut (en général,
arrêt du processus)
Ignorer le signal (pas tous)
Gérer le signal (pas tous)

Gestion des permissions

Seuls les processus d’un même utilisateur peuvent
s’envoyer des signaux
Pas de kill sur le processus du voisin
Action possibles pour un signal

Quelques signaux
Signal Valeur Action Description
SIGHUP 1 T le terminal se ferme
SIGINT 2 T Ctrl C au clavier
SIGKILL 9 TD terminer le processus
SIGSEGV 11 M erreur de segmentation
SIGCHLD - I terminaison d’un fils
Action par défaut : T=terminer, D=défaut
obligatoire, M=image mémoire, I=ignorer
Gestion des signaux
Deux étapes
Écrire la fonction gérante (en C)
Associer fonction et signal (appel système)

Exemple (pseudo-code)
void ma_gerante ( int numero Si gnal ) {
/∗ contenu de l a gé r a n t e ∗/
}
i n t main ( ) { . . .
a ss o c i er ( nom Signal , ma_gerante ) ;
/∗ à p a r t i r de l à , ma_gerante ( ) se ra appel ée
pour le s ig n a l i d e n t i f i é par nom Signal ∗/
}
Association signal et fonction
L’appel système est sigaction()
Signature
#i nclude < si gn al . h>
int si gac t i on ( int signum ,
const st r uct si gact i on ∗act ,
struct si gact i on ∗ol dact ) ;

Avec
struct si gact i on {
void ( ∗sa_ handl er ) ( int ) ;
si gset _ t sa_mask ;
int sa_ f l ags ;
}
Exemple
void ger e ( int si g ) {
p r i n t f ( " Re cu SIGSEGV (%d ) \ n" , s i g ) ;
ex i t ( 1 ) ;
}
int main ( ) {
struct si g ac t i o n act ;
si gempty set (& act . sa_mask ) ;
act . sa_ f l ags = 0;
act . sa_ handl er = ger e ;
si g ac t i o n ( SIGSEGV , &act , NULL) ;
puts (NULL ) ;
}
Quelques info en plus

Pour plus de détails, lire le man

Pour ignorer un signal, mettre SIG_IGN dans
sa_handler
Pour l’action par défaut, mettre SIG_DFL dans
sa_handler
Les signaux d’une même catégorie ne sont pas
empilés : une rafale d’un même signal peut activer
une seule invocation de la fonction gérante
Plan
1 Introduction

2 Communication par signaux

3 Communication par tubes

4 Interblocages

6
Tubes

Définition
Espace mémoire accessible en lecture et/ou écriture
Deux bouts : un pour l’écriture, l’autre pour la
lecture
L’espace est géré par le SE
Processus Processus
Tube
A B
Tube et processus
Descripteurs de fichiers
Pour un processus, un tube est un
peudo-périphérique
Une fois le tube ouvert, chaque extrémité se
manipule comme fichier

Deux sortes de tubes

Tubes simples (majoritairement utilisés)
Tubes nommés (plus complexes, plus expressifs,
mais plus rares)
Tube simples
Un tube simple est crée à la demande d’un
processus.
Création : appel système pipe() qui retourne deux
descripteurs de fichier
Utilisation : read(), write(), close()

Exemple :
int emboi s [ 2 ] ; /∗ dé c la r a t i o n ∗/
e r r = pi pe ( emboi s ) ; /∗ c r é a t io n ∗/
ec r i t s = w r i t e ( embois [ 1 ] , . . . ) ;
l u s = re ad ( embois [ 0 ] , . . . ) ;
Tubes simple

embois[1] embois[0]
Processus

Tube
Communication par tube

Partage par fork

Un tube créé par un processus, ainsi que les
descripteurs de fichiers sont partagés lors d’un fork()

Ce partage permet alors la communication entre

père et fils
Le tube devient une zone mémoire partagée entre le
père et le fils
Communication par tube
Caractéristiques des tubes

Flot de donnée (caractères)

File (premier entré premier sorti, ou FIFO)
Chaque élément lu est consommé
Pas de déplacement possible (lseek)
Les tubes simples sont limité à la hiérarchie issue du
processus créateur
La taille du tube est bornée
Synchronisation
Lecture si le tube est vide
Bloquante si un écrivain existe
Retourne 0 si aucun écrivain

Écriture
Bloquante si le tube est plein
Signal SIGPIPE envoyé si aucun lecteur existe

Opérations synchronisées
Exclusion mutuelle : une après l’autre
Bonnes pratiques
Règle importante de prévention
Toujours fermer les bouts inutiles

Exemple

(Père) (Fils)
Créer le tube -
fork() -
Retour du fork() Retour du fork()
Fermer un des deux Fermer l’autre bout du
bouts du tube tube
Bonnes pratiques
Corollaire
Pour une communication à deux sens
Il faut deux tubes
Tubes shell
$ chercheLe | deColle
création du tube : pipe(p);
clonage : fork();
si père alors
fermer sortie du tube : close(p[0]);
fermer la sortie standard : close(1);
associer entrée du tube à la sortie standard :
dup2(p[1], 1);
fermer le doublon : close(p[1]);
se recouvrir par chercheLe : exec..();
sinon si fils alors
analogue mais dans l’autre sens...
fin
Limites des tubes simples

Héritage des processus obligatoires

Partage entre plus de deux processus difficile à gérer
Tubes nommées
Principe
Les tubes ne sont pas hérités mais désignés
Donc permet la communication par tubes sans se
baser sur la hiérarchie des processus

Caractéristiques
Une structure en mémoire système (comme un tube
simple)
La possibilité de rendez-vous entre processus
La gestion des droits
Tubes nommées

Utilisation d’un fichier spécial, dit « tube »

Crée avec mkfifo
Les droits du fichiers sont les droits du tube
Le fichier est et reste vide : le tube est en mémoire
Ouvrir le fichier c’est accéder au tube

Le rendez-vous
L’ouverture du fichier est bloquante tant qu’il n’y a
pas un lecteur et un écrivain
Autres moyens de communication

Files de messages
Mémoire partagée
Sémaphores
Threads
Réseau
Système de fichiers
Bus logiciels
File de messages (Unix)
Espace mémoire
Géré par le SE
Protection et synchronisation faites par le SE

Contient des messages (datagrames)

Les messages sont étiquetés
Un processus peut y déposer un message
Un processus peut y retirer un message le
premier message de la file
ou le premier avec une étiquette spécifique
Mémoire partagée

Espace partagée non gérée par le SE

Protection et synchronisation faites par les processus
via des primitives systèmes (comme les sémaphores)

Projection en mémoire des fichiers (mmap)

Alternative à la manipulation par descripteurs
Permet le partage entre plusieurs processus d’un
même fichier projeté
Threads
ou processus légers

Plusieurs fils d’exécution pour un même processus

Chaque thread possède une pile et un compteur
ordinal
Les threads partagent (entre autre) le code, les
données statiques, le tas et les fichiers ouverts du
processus
Ce partage doit être synchronisé par les threads
eux-mêmes via des primitives systèmes
Réseau

Communication distante
Objectif primaire : faire communiquer des
applications sur des ordinateurs distincts
Peut être utilisé pour des applications sur une même
machine

Avantages
Le SE peut optimiser l’efficacité du traitement
Exemple : client/serveur X
Système de fichier
Les fichiers ne sont pas exclusifs à un processus
Les processus peuvent utiliser les fichiers pour
communiquer entre eux
L’accès et la protection sont connus

Exemples
Répertoire temporaire pour passer des données
(compilation, etc.)
Fichiers spéciaux pour initier un autre type de
communication (tubes nommés, etc.)
Spool (impression, cron job, etc.)
Bus logiciels
Support de communication de haut niveau
Permet de faire communiquer des applications via
des objets partagés et des envois de messages
Généralement pour le réseau (ex. CORBA) mais
existe aussi pour les SE.

Exemple : D-BUS
-Un démon gérant les services et les clients
-Une bibliothèque utilisable par les processus --
-Démon et bibliothèque utilisent des primitives
systèmes pour faire le travail de communication, de
synchronisation et de protection
Plan
1 Introduction

2 Communication par signaux

3 Communication par tubes

6
4 Interblocages

5
Interblocages

Alias
Deadlock
Verrou fatal
Étreinte fatale
Embrasse mortelle

Principe
Plusieurs processus sont bloqués entre eux et ne
peuvent progresser
Ressources

Quelques ressources (au sens large)

Imprimante
CPU
Sémaphore
Section critique

Ressources et interblocages
Les interblocages découlent de l’allocation des
ressources
Ressources

Événement liés auxressources

Demander la ressource
Utiliser la ressource
Libérer la ressource

Si un processus demande une ressource déjà prise

Erreur
Attente
Attente temporisée
Interblocage
Définition Formelle
Un ensemble de processus sont en interblocage si
chaque processus dans cet ensemble est en attente
d’un événement que seulement un autre processus
de cet même ensemble peut déclencher "Tanenbaum"
L’événement peut-être est la libération d’une
ressource

En cas d’interblocage un processus ne peut

ni continuer son exécution
ni libérer une ressource
Caractérisation d’un interblocage
Les 4 conditions nécessaires et suffisantes de
l’interblocage
exclusion mutuelle : la ressource est soit disponible,
soit assignée à un processus
détention multiple : un processus qui détient une
ressource peut en demander d’autres
pas de réquisition : une ressource détenue par un
processus doit être libérée par lui
attente circulaire : il doit y avoir un cycle dans les
attentes d’évènement
Description desallocations
Graphe bipartie orienté

A S D

T U
R B C
(a) (b) (c)

(a) Ressource R assignée au processusA

(b) Processus B demande et attend S
(c) C et D sont en interblocage
Gestion des interblocages

Quatre stratégies
Ignorer le problème
Détecter et résoudre
Prévenir le problème
Éviter dynamiquement
Ignorer le problème
Principe
Prétendre que le problème n’existe pas

Raisonnable si
Interblocages rares
Autres solutions trop coûteuses/restrictives

Avantage
Facile à comprendre
Facile à mettre en œuvre
Détecter et résoudre
Principe
Vérifier périodiquement si les processus sont en
interblocage et les débloquer

Comment savoir si il y ainterblocage

Modélisation et analyses de graphe

Comment débloquer (sans tout casser)

Retirer de force une ressource
Restauration d’un état antérieur (roolback)
Éliminer un processus
Prévenir le problème

Principe
Éliminer une condition de l’interblocage

Exemples
Spooling : seul un processus a la ressource
Ressources demandées d’un coup au début
Permettre la préemption
Ordonner les ressources (donc les demandes)
Éviter dynamiquement

Principe
Forcer l’ordonnanceur à faire le bon choix
C’est possible via des infos supplémentaires

Idée
Un état est sûr s’il existe un séquence d’allocations
qui permet aux processus d’aller jusqu’au bout
Exécuter une allocation que si l’état qui en résulte
est sûr
Résolutions en pratique

Pas de solutionultime
Le coût et l’efficacité d’une technique dépend
fondamentalement de la nature des ressources

En pratique,
Les SE actuels ignorent le problème
Seuls les SE critiques préviennent ou évitent ce
genre de problème
Problème cousin - Famine

Synonymes
Starvation
Privation de ressource

Définition
Un groupe de processus partagent une ressource
(sans interblocage) mais certains processus (voire
tous) n’obtiennent jamais la ressource