2.

Les Processus
Introduc0on
• Défini&on: Un processus est une instance d’un programme
qui s’exécute.

• = « tache », « job » ou « travail ».

1
2. Les Processus
Introduc0on
• Il a un état d’exécu.on :
• compteur de programme, la pointeur sur la pile…
• Il dispose de zones et de ressources allouées temporairement :
• données, état des registres CPU, occupa.on mémoire…
• Il peut avoir besoin de ressources matérielles spécifiques :
• e.g. périphériques d’entrée/sor.es…

2
2. Les Processus
Introduction
• Le système d’exploita1on gère les
ressources matérielles pour le
comptes des applica1ons.
• Une applica*on : un programme qui
est stockés sur disque ou su, dans le
cloud… C’est une en1té sta1que.
• Un processus : l’état d’un programme
en cours d’exécu1on, chargé en
mémoire… C’est une en1té ac1ve.
3
2. Les Processus
Introduc0on
• Un programme peut être lancé plusieurs fois => plusieurs
processus sont créés.

4
2. Les Processus
À quoi ressemble un processus?
• Sta$que (au lancement du processus) : Vmax
• Code (text, read-only)
• Données sta$ques (données & variables).
• Le tas (heap) :
• Données allouées dynamiquement pendant
l’exécu$on.
• La pile (stack) :
• Augmente et diminue selon une stratégie LIFO
• Les appels de fonc$ons et variables locales aux
fonc$ons exigent une structure de donnée
dynamique V0
• Adresse de retour de fonc$on. 5
2. Les Processus
À quoi ressemble un processus?
• Espace d’adressage : la représenta1on d’un Vmax
processus en mémoire.

Adresses virtuelles
• Les adresses virtuelles sont à dis1nguer
des adresses physiques

• Table : mapping entre les adresses

virtuelles et les adresses physiques.
V0
6
2. Les Processus
À quoi ressemble un processus?
• Pour un processus : des par.es de l’espace Vmax
d’adressage virtuel peut ne pas être
allouées.

Adresses virtuelles
• L’espace physique peut ne pas être
suffisant pour tous les états des processus
en cours.

V0
DRAM 7
2. Les Processus
Etats d’un processus
• Le système d’exploita1on doit savoir à tout moment qui fait
quoi et où en est chacun des processus :
• Program counter
• Registres du CPU
• Pointeur sur la pile
• …
• Pour sauvegarder toutes ces informa1ons :
=> Process Control Block

8
2. Les processus
Process Control Block (PCB)
• Le système d’exploita1on main1ent un
PCB par processus.
• C’est une structure de données.
• Créée et ini1alisée au lancement du
processus.
• Mise à jour tout au long de l’exécu1on
d’un processus

9
2. Les processus
U-lisa-on des PCB
• A chaque un
swap entre
processus est
effectué =>
Context switch

CPU regs =

10
2. Les processus
Context Switch
• Context switch :
• Changer l’affecta.on du CPU d’un processus à un autre
• Modifier les infos du CPU : du contexte d’un processus à un autre
contexte.
• Opéra.on très couteuse !
• Coûts pour charger et pour sauvegarder les instruc.ons.
• Perte des avantages des données en cache.

11
2. Les processus
Etats
Un processus peut être en exécu/on (running) ou libre (idle)

12
2. Les processus
Etats

13
2. Les processus
Etats
Au cours de sa vie, un processus passe par plusieurs états :
• Transitoire (new) : à la créa5on.
• Prêt (ready) : prêt à passer en mode exécu5on.
• Ac5f (running) : en cours d’exécu5on (mode noyau ou u5lisateur).
• Endormi (wai5ng) : en a>ente d’un évènement (a>ente d’entrée/sor5e, d’un
signal, de la terminaison d’un processus).
• Terminé (terminated).

14
2. Les processus
Créa/on
Deux mécanismes pour la créa1on de
processus :
• Fork =
• PCB du parent est copié dans le nouveau PCB du fils.
• Processus fils con1nue l’exécu1on à la suite de
l’instruc1on fork.
• Exec =
• Charge un nouveau programme
• PCB du fils pointe vers l’instruc1on du nouveau
program.

15
2. Les processus
Création
• Sous Unix, le processus qui est considéré comme parent à tous les
autres processus :
init

• Sous android, le processus qui est considéré comme le parent à

tous les processus d’applica9ons :
Zygote

16
2. Les processus
Ordonnanceur
• L’ordonnanceur (en anglais scheduler)
est la par0e du système d’exploita0on
qui est chargée de l’arbitrage du
processeur.
=> Il détermine lequel des processus
prêts sera affecté au CPU et la durée
d’affecta0on.

17
2. Les processus
Ordonnanceur
• Pour que cela fonc-onne, le système
d’exploita-on :
• Préempte : interrompt un processus en
cours d’exécu-on et sauvegarde son
contexte.
• Ordonnance : choisit le prochain
processus qui sera affecté au CPU.
Ca doit être efficace et op-male

18
2. Les processus
Ordonnanceur
• A quelle fréquence, l’ordonnanceur doit être exécuté ?

19
2. Les processus
Ordonnanceur
• A quelle fréquence, l’ordonnanceur doit être exécuté ?

Le temps alloué au CPU pour le traitement doit être majoritaire.

20
2. Les processus
Ordonnanceur : impact des E/S

21
2. Les processus
Interac0on entre processus
• Mécanisme IPC : inter-processus communica.on
• Transfert de données/info entre espaces d’adressage.
• Main:ent la protec:on et l’isola:on de 2 processus.
• Flexibilité et performance.

22
2. Les processus
Interac0on entre processus
• IPC : Par message IPC
• Le SE fournit des canaux de communica8on : buffer partagé.
• Processus écrivent et lisent à par8r du buffer partagé.

+ Géré par le SE
- Surcoût

23
3. Les threads
Introduc1on
Introduction Vmax

• Un processus est représenté par :

1. Un espace d’adressage
2. Un contexte d’exécution (PCB)
V0

• Ce type de processus ne peut s’exécuter que sur un seul processeur à

chaque instant !

59
24
3. Les threads
Introduc1on

25
3. Les threads
Introduc1on
• Un thread se comporte comme un vendeur dans une bou2que :
• C’est une en2té ac2ve : travail sur des commandes clients.
• Il travaille simultanément avec d’autres : plusieurs vendeurs travaillent sur des
commandes.
• Nécessite un certaine coordina2on : partage des ou2ls de ges2on, des
caisses… avec d’autres vendeurs.

26
3. Les threads
Processus vs. thread

27
3. Les threads
Défini1on
• Un thread (ou fil d’exécu+on) est l’exécu0on d’une procédure/fonc0on en
parallèle de la fonc0on principale d’un processus
• Un processus comporte un ou plusieurs threads.
• Le PCB du processus con0ent pour chaque thread :
• un état
• un contexte processeur
• En revanche, toutes les autres ressources (mémoire, fichiers, etc…)
sont partagées par tous les threads du processus :
→ c’est au programmeur de les arbitrer

28
3. Les threads
Processus léger
• Les threads sont souvent appelés « processus légers ».
• Ils bénéficient des mêmes avantages en terme de parallélisme, que les
processus (l’ordonnanceur considère chaque thread individuellement).
• Avantages par rapport aux processus :
• la commutaEon de contexte est plus rapide (même PCB),
• la communicaEon entre eux est plus rapide (pas besoin d’appel système).

29
3. Les threads
Pourquoi cela est-il intéressant et u6le ?

• Mul$-threading => parallélisa$on => accéléra$on de l’exécu$on.

• Mul$-threading => Spécialisa$on (priorisa$on, cache plus efficace…)

30
3. Les threads
Pourquoi cela est-il intéressant et u6le ?
• Mul$threading => L’espace d’adressage
partagé (donc alloué une seul fois)
• Op$misa$on de la ges$on de la mémoire.
• La communica$on des données entres
threads est plus simple à gérer et plus
efficiente.

31
3. Les threads
Est-ce u0le quand on a un seul CPU ?
• Ou de façon générale, quand : # Threads > # CPU

Si (t_idle) > (2 * t_ctx_switch) => OK

Cela est valable autant pour les threads que les processus.

Pour les processus : l’une des étapes les plus couteuses dans la
commutaNon de contexte est :
• La créaNon de du mapping entre l’adressage virtuel et
l’adressage physique.

=> t_ctx_switch thread < t_ctx_switch processus.

32
3. Les threads
Pour se fixer les idées…
Lesquelles de ces affirma.ons s’appliquent aux processus, aux threads
ou au deux ?
• Peuvent se partager le même espace d’adressage.
• Prend plus de temps pour effectuer une commuta.on de contextes.
• A un contexte d’exécu.on.
• habituellement permet de mieux .rer profit du cache.
• U.lise des mécanisme de communica.ons.

33
3. Les threads
En pra/que…
On a besoin de :
• Structure de données pour décrire chaque thread : iden4fica4on, ressources
u4lisée…
• Mécanismes pour créer et pour gérer des threads.
• Mécanismes pour assurer une coordina0on entre les threads qui s’exécutent de
façon concurrente, dans le même espace d’adressage.

34
3. Les threads
Ges-on de la concurrence d’accès

35
3. Les threads
Concurrence sans problème

36
3. Les threads
Concurrence probléma6que

37
3. Les threads
Quelques défini4ons
• Une ressource est dite ressource critique lorsque des accès
concurrents à cette ressources peuvent résulter dans un état
incohérent.
• On parle aussi de situation de compétition (race condition) pour
décrire une situation dont l’issue dépend de l’ordre dans lequel les
opérations sont effectuées.
• Une section critique est une section de programme manipulant une
ressource critique.

38
3. Les threads
Ges-on de la concurrence d’accès
• Nécessite de la coordina/on.
• L’exclusion mutuelle : accès exclusif à un seul
thread à chaque instant.

• Mécanismes d’a2ente entre thread :

• Condi/ons spécifiques avant de pouvoir s’exécuter.

=> Mécanisme de synchronisa:on

39
3. Les threads
L’exclusion mutuelle
• Une sec'on de programme est dite atomique lorsqu’elle ne peut pas
être interrompue par un autre processus/thread manipulant les
mêmes ressources cri'ques.
→ c’est donc une atomicité rela've à la ressource

• Un mécanisme d’exclusion mutuelle sert à assurer l’atomicité des

sec'ons cri'ques rela'ves à une ressource cri'que.
→ en anglais : mutual exclusion, ou mutex

40
3. Les threads
L’exclusion mutuelle
• Mise en œuvre abstraite :

41
3. Les threads
L’exclusion mutuelle
Critères :
• Exclusion : deux tâches ne doivent pas se trouver en même temps en SC.
• Progression : une tâche doit pouvoir entrer en SC si aucune autre ne s’y trouve.
• Équité : une tâche ne devrait pas a:endre indéfiniment pour entrer SC.
• L’exclusion mutuelle doit fonc@onner dans un contexte mul7-cœurs.

42
3. Les threads
L’exclusion mutuelle
• Une (mauvaise) solu/on possible : l’a4ente ac/ve
• U/liser un booléen partagé comme « verrou ».

• Le processus qui a4end consomme du temps processeur (d’où le nom

d’a4ente ac/ve).
• Ce4e approche n’assure par l’exclusion!
→ verrou est lui même une ressource cri/que.
43
3. Les threads
L’exclusion mutuelle
La bonne solu+on :
• On associe à la ressource un jeton, que les processus/threads
peuvent prendre et reposer
• Seul le processus/thread possédant le jeton devrait manipuler la
ressource
• Donc, si un processus/thread souhaite manipuler la ressource et que
le jeton est pris, il doit d’abord a@endre que le jeton redevienne
disponible
• U+lisa+on d’un sémaphore ini+alisé à 1
44
3. Les threads
L’exclusion mutuelle
Sémaphore
• Ressource servant à la synchronisa2on.
• no2on inventée par Edsger W. Dijkstra.

• Analogie à une pile de jetons.

• con2ent ini2alement un certain nombre de jetons.
• Les processus peuvent poser (sem_post) ou prendre (sem_wait) un jeton.
• comme son nom, l’appel sem_wait peut être bloquant: lorsqu’un processus
tente de prendre un jeton alors que la pile est vide, il se bloque en aJendant
qu’un jeton soit posé.
45
3. Les threads
L’exclusion mutuelle
• Exemple de mise en œuvre :

46
3. Les threads
L’exclusion mutuelle
A u$liser avec discernement !
• Certaines opéra$ons sur la ressource cri$ques ne nécessitent pas forcément
d’exclusion mutuelle.
→ exemple : lecture de la valeur du compte (si on accepte que la valeur lue
devienne rapidement invalide…)
• Les sec$ons cri$ques sont un mal nécessaire:
• un mal, parce qu’elles empêches le parallélisme qu’on a eu tant de mal à meEre en
place… elles réduisent donc les performances.
• nécessaire, parce qu’elles garan$ssent l’intégrité des ressources cri$ques

Conséquence :
• Les éviter lorsqu’on le peut (e.g. en concevant des structures de données
toujours cohérentes).
47
3. Les threads
L’exclusion mutuelle
• Réduire au strict minimum l’u+lisa+on des mécanisme d’exclusion
mutuelle :

48
3. Les threads
L’exclusion mutuelle
Inter-blocage (deadlock) :
Situa0on où plusieurs tâches sont bloquées car chacune a;end un
événement que doit produite une autre.
Un exemple classique se produit lorsque deux tâche a;endent chacune
un « jeton » détenu par l’autre :

49
3. Les threads
Quelques problèmes typiques de synchronisa9on
Producteurs/consommateurs
• Un ensemble de processus, divisé en deux catégories, partage une zone
mémoire.
• Les premiers (producteurs) remplissent la mémoire partagée, avec des
éléments.
→ la mémoire ne peut contenir qu’un nombre d’éléments limité et
connu à l’avance
• Les seconds (consommateurs) u@lisent ces éléments et les re@rent de la
mémoire.

Exemple : file d’impression.

50
3. Les threads
Quelques problèmes typiques de synchronisa9on
Producteurs/consommateurs

• Un producteur doit se bloquer lorsque la

mémoire partagée est pleine.
• Un consommateur doit se bloquer lorsque la
mémoire partagée est vide.
51
3. Les threads
Quelques problèmes typiques de synchronisa9on
Producteurs/consommateurs : Principe de la solu3on
• U"lisa"on de deux sémaphores, implémentant les deux critères de
blocage :
• l’un représente le nombre de cases libres.
• l’autre représente le nombre de cases occupées.

52
3. Les threads
Quelques problèmes typiques de synchronisa9on
Producteurs/consommateurs : Principe de la solu3on

53
4. Ordonnancement des processus
Introduction
Rappel
Rôle de l’ordonnanceur : choisir, parmi tous les processus éligibles,
lequel va devenir élu → poli<que d’ordonnancement.

54
4. Ordonnancement des processus
FIFO sans préemp4on
• Premier arrivé, premier servi
• Ordonnancement coopéra'f (pas de préemp4on) : les processus
rendent la main « de leur plein gré »,
• lorsqu’ils se terminent,
• lorsqu’ils se bloquent,
• lorsqu’ils font l’appel système yield.

Note : L’appel système yield sert au processus à céder le processeur aux

autres.
55
4. Ordonnancement des processus
FIFO sans préemp4on
Inconvénients
• Temps de réponse dépend du processus qui a la main
• Tant qu’il ne rend pas la main, les autres doivent a7endre
• Pénalise les processus courts
• Propor9on temps d’a7ente / temps d’exécu9on

56
4. Ordonnancement des processus
FIFO sans préemp4on
Avantages
• simple
• surcoût faible
• équitable

Adapté dans les contextes suivants :

• Nombreux cœurs de calcul.
• Processus très fréquemment bloqués (ges@ons E/S).
• Machine peu puissante, ou le surcoût doit être minimisé.

57
4. Ordonnancement des processus
FIFO sans préemp4on
U"lisa"ons :
• certains systèmes batch
• faible surcoût, meilleure u"lisa"on du/des processeur(s)
• pas de contrainte de temps de réponse
• Mac OS < X (mul"tâche coopéra"f)
• faible surcoût, intéressant pour une machine lente
• Processus « temps réel » sous Linux
• processus de ges"on des E/S, fréquemment bloqués mais nécessitant une
réac"on très rapide aux interrup"ons matérielles

58
4. Ordonnancement des processus
Tourniquet
• FIFO avec préemption
• Chaque processus reçoit un quantum de temps
• Une fois le quantum épuisé, le processus passe
la main au retourne dans la file d’attente
• En anglais : round robin (ruban rond)

59
4. Ordonnancement des processus
Tourniquet
• En diminuant la durée du quantum :
• le temps de réponse diminue, mais…
• le surcoût augmente
• Le quantum idéal dépend de la durée moyenne
d’une interac;on et du nombre de processus…

60
4. Ordonnancement des processus
Tourniquet : avantages et inconvénients
+ temps de réponse borné, indépendamment des
processus (calculs ou E/S)
+ équitable
- très sensible au choix du quantum
- défavorise les processus orientés E/S (bloqués
avant la fin de leur quantum)

61
4. Ordonnancement des processus
Shortest Job Next
• On donne toujours la main à celui qui va me4re le moins de temps
avant de se bloquer / terminer
• suppose d’avoir une connaissance / es9ma9on de ce temps pour chaque
processus : hypothèse forte
• Avantages
• maximise le temps de réponse, le débit (nombre de processus terminés par
unité de temps)
• Inconvénients
• surcoût
• inéquitable, famine possible (processus calculatoires)

62
4. Ordonnancement des processus
Highest Response Ra6o Next
Variante de la stratégie précédente :
• on prend en compte le ra3o du temps que le processus a passé à
a7endre sur le temps dont il a besoin
• Supprime le problème de famine
• plus un processus a7end, plus il augmente ses chances d’obtenir la main
• Mais suppose toujours la connaissance du temps d’exécu3on

63