$course$/QCM de NSI/Terminale/Processus et système Approfondissement de la gestion des processus par
un système d'exploitation : notion de processus,
états, ordonnancement, communication entre
processus, synchronisation par verrous, risque
d'interblocage et notion de signal.

]]> Processus et système — Q01 : Notion de processus Qu'est-ce qu'un processus ?

]]> Il faut bien distinguer la notion de
programme (un fichier exécutable
sur le disque) et celle de processus
(une instance dynamique de ce programme
en cours d'exécution). Sous Linux, les
commandes ps ou top permettent
d'observer les processus actifs ; sous
Windows, on utilise le Gestionnaire des
tâches.

]]> 1.0 0.0 0 true true abc Un programme en cours d'exécution, accompagné de sa mémoire, de ses ressources et de son contexte (registres, pile d'appels)

]]> C'est une abstraction centrale du
système d'exploitation. Un même
programme lancé deux fois donne
deux processus indépendants, qui
disposent chacun de leur propre
mémoire et de leur propre contexte
d'exécution.

]]> Un type particulier de mémoire

]]> Un processus utilise de la mémoire
(sa zone de mémoire), mais il
n'est pas lui-même un type de
mémoire.

]]> Un fichier exécutable stocké sur le disque

]]> Cette description correspond plutôt
à un programme au sens du
fichier exécutable. Un processus
est, lui, dynamique : il représente
un programme en cours
d'exécution.

]]> Une fonction définie dans un programme Python

]]> Une fonction n'est qu'un fragment
de code à l'intérieur d'un
programme. Un processus est une
notion bien plus large, qui
englobe l'intégralité d'un
programme en exécution.

]]> Processus et système — Q02 : Fil d'exécution Qu'est-ce qu'un fil d'exécution
(parfois appelé thread) ?

]]> Une comparaison utile : un processus
est comparable à une maison
indépendante (sa mémoire est isolée),
tandis qu'un fil d'exécution est
comparable à une pièce dans cette
maison (la mémoire reste partagée
avec les autres pièces).

]]> 1.0 0.0 0 true true abc Un protocole utilisé sur Internet

]]> Un fil d'exécution est une notion
interne au système d'exploitation,
sans rapport avec les protocoles
réseau.

]]> Une unité d'exécution légère au sein d'un processus, qui partage la mémoire avec les autres fils du même processus

]]> Plusieurs fils d'exécution dans un
même processus permettent de
paralléliser des tâches tout en
partageant les données. Cette
approche est plus légère que de
créer plusieurs processus, mais
plus délicate à gérer en raison
des problèmes de synchronisation.

]]> Un fichier de configuration du système

]]> Cette description ne correspond pas
à la notion de fil d'exécution,
qui désigne une unité d'exécution
au sein d'un programme.

]]> Un type de fichier sur le disque

]]> Un fil d'exécution n'a aucune
existence sur le disque. C'est une
notion d'exécution qui n'apparaît
qu'à l'instant où un programme
tourne.

]]> Processus et système — Q03 : Identifiant de processus Que désigne le PID d'un processus ?

]]> Sur les systèmes Unix, la commande
ps affiche les PID en cours.
kill <PID> envoie le signal
TERM par défaut, et
kill -9 <PID> envoie le signal
KILL, qui est plus brutal et ne
peut pas être ignoré par le
processus visé.

]]> 1.0 0.0 0 true true abc Un pilote interne pour gérer les processus

]]> Cette interprétation est
fantaisiste. Le sigle PID désigne
simplement un identifiant
numérique unique attribué par le
système.

]]> Un numéro unique attribué par le système d'exploitation à chaque processus pour pouvoir l'identifier

]]> Le PID, pour Process IDentifier,
permet d'identifier les processus
de manière unique. On l'utilise
par exemple avec la commande
kill <PID>. Sur les systèmes
Unix, le numéro $1$ est
traditionnellement attribué au
processus de démarrage.

]]> Un descripteur de permissions

]]> Les permissions et le PID sont des
notions distinctes. Le PID
identifie un processus ; les
permissions définissent ce que ce
processus peut faire.

]]> Un domaine personnel sur Internet

]]> Aucun rapport avec les domaines
Internet. Le PID est un numéro
interne au système d'exploitation.

]]> Processus et système — Q04 : États d'un processus Quels sont les états principaux par
lesquels passe un processus au cours de
sa vie ?

]]> Sous Linux, la commande ps -aux
affiche l'état de chaque processus :
R pour running (en exécution),
S pour sleeping (en sommeil),
D pour disk wait (en attente
d'entrée-sortie disque), Z pour
zombie.

]]> 1.0 0.0 0 true true abc Démarré et terminé, uniquement

]]> Ces deux états ne suffisent pas à
décrire le cycle de vie d'un
processus. Un processus peut être
prêt à s'exécuter, en train de
s'exécuter, ou bloqué en attente
d'une ressource.

]]> Sain et malade

]]> Cette description fantaisiste n'a
aucun rapport avec la gestion des
processus.

]]> Prêt, en exécution, bloqué (en attente d'une ressource ou d'une entrée-sortie), terminé

]]> C'est le modèle classique en
système d'exploitation.
L'ordonnanceur gère les
transitions entre l'état « prêt »
et l'état « en exécution ».
L'état « bloqué » correspond à
l'attente d'une ressource (un
fichier, le réseau, un verrou).

]]> Visible et caché

]]> La visibilité d'un processus pour
l'utilisateur n'a pas grand
rapport avec son cycle de vie
interne au système.

]]> Processus et système — Q05 : Ordonnanceur Quel composant choisit quel processus
reçoit le processeur à chaque instant ?

]]> Plusieurs stratégies d'ordonnancement
existent : le tour de rôle, la
priorité statique ou dynamique, ou
encore l'ordonnancement fondé sur la
latence. Pour les systèmes
d'exploitation à contraintes temps
réel, il faut des garanties strictes
sur les délais d'exécution.

]]> 1.0 0.0 0 true true abc L'interpréteur de commandes (ou shell)

]]> L'interpréteur de commandes sert
à lancer des programmes, mais ce
n'est pas lui qui décide à quel
moment chaque processus reçoit le
processeur.

]]> Le pilote

]]> Un pilote est un module qui
permet au système de communiquer
avec un périphérique matériel
(carte réseau, imprimante, etc.).
Ce n'est pas son rôle de choisir
quel processus s'exécute.

]]> L'ordonnanceur, qui est un composant du noyau du système d'exploitation

]]> L'ordonnanceur décide selon
plusieurs critères : la priorité
du processus, l'équité globale
entre les processus, la latence
attendue. Sous Linux,
l'ordonnanceur en place s'appelle
Completely Fair Scheduler.

]]> L'utilisateur, à chaque instant

]]> L'utilisateur peut influencer
indirectement l'ordonnancement
(en modifiant la priorité d'un
processus, par exemple), mais il
ne décide pas à chaque instant
quel processus reçoit le
processeur.

]]> Processus et système — Q06 : Parallélisme et concurrence Quelle est la différence entre
parallélisme et concurrence ?

]]> Aujourd'hui, les processeurs
multi-cœurs offrent un véritable
parallélisme. En Python, le module
multiprocessing permet du
parallélisme effectif, alors que le
module threading n'offre que de
la concurrence dans l'implémentation
de référence du langage.

]]> 1.0 0.0 0 true true abc La concurrence désigne plusieurs tâches en cours logiquement (qui se partagent un même processeur en alternant). Le parallélisme désigne plusieurs tâches s'exécutant réellement en même temps sur des cœurs différents

]]> Avec un seul cœur, on peut être
en concurrence (les tâches
alternent), mais pas en
parallélisme. Plusieurs cœurs
permettent un véritable
parallélisme.

]]> La concurrence n'existe pas en informatique

]]> La concurrence est au contraire
un concept fondamental, présent
dans la plupart des systèmes
d'exploitation modernes.

]]> Aucune différence, ce sont deux mots pour la même chose

]]> La distinction entre les deux
notions est importante en
informatique, comme expliqué dans
la bonne réponse.

]]> Le parallélisme est toujours plus rapide

]]> Cette affirmation est trop
simpliste. Le parallélisme peut
accélérer un calcul, mais il
introduit un coût de
synchronisation et n'est pas
toujours bénéfique.

]]> Processus et système — Q07 : Mémoire partagée entre fils d'exécution Pourquoi les fils d'exécution d'un même
processus partagent-ils leur mémoire ?

]]> C'est un compromis classique entre
performance et sécurité. Les fils
d'exécution communiquent rapidement,
mais leur partage de mémoire est
risqué. Les processus, à l'inverse,
sont fortement isolés, mais leur
communication est plus coûteuse.

]]> 1.0 0.0 0 true true abc Pour permettre une communication rapide entre fils d'exécution (lire et écrire des variables communes), au prix d'une nécessaire gestion de la synchronisation

]]> C'est l'avantage majeur des fils
d'exécution par rapport aux
processus. Cette communication
rapide est cependant source de
bugs subtils si l'on ne
synchronise pas correctement les
accès aux variables partagées.

]]> Par défaut, ils ne partagent rien

]]> Le partage de la mémoire est
précisément la caractéristique
qui distingue les fils
d'exécution des processus.

]]> Pour économiser des cœurs de processeur

]]> Le partage de la mémoire ne
permet pas d'économiser des
cœurs. Son intérêt principal
tient à la rapidité de la
communication entre fils
d'exécution.

]]> Aucune raison particulière

]]> Le partage de la mémoire entre
fils d'exécution répond à un
besoin précis, comme expliqué
dans la bonne réponse.

]]> Processus et système — Q08 : Signal Qu'est-ce qu'un signal sous Unix ?

]]> La commande kill -<signal> <PID>
envoie un signal donné au processus
désigné. Par défaut, c'est
SIGTERM (numéro $15$) qui est
envoyé. Le signal SIGKILL
(numéro $9$) est plus brutal : le
processus ne peut pas le bloquer ni
le retarder.

]]> 1.0 0.0 0 true true abc Un message textuel envoyé sur un réseau social

]]> Cette interprétation littérale du
mot « signal » est sans rapport
avec sa signification en
informatique système, où il
désigne un mécanisme du système
d'exploitation.

]]> Une instruction du processeur

]]> Les signaux sont une notion du
système d'exploitation, et non
du jeu d'instructions du
processeur.

]]> Une notification asynchrone envoyée à un processus pour lui demander une action (terminaison, suspension, reprise…)

]]> Quelques signaux courants :
SIGTERM (demande polie de
terminaison), SIGKILL
(terminaison brutale, qui ne
peut pas être ignorée), SIGINT
(interruption clavier, par
exemple Ctrl+C), SIGHUP
(rechargement de la
configuration).

]]> Un protocole utilisé sur Internet

]]> Les signaux n'ont aucun rapport
avec les protocoles réseau ; ils
sont locaux à un système
d'exploitation.

]]> Processus et système — Q09 : Lister les processus Quelle commande Unix affiche la liste
des processus en cours d'exécution ?

]]> Sous Windows, on peut utiliser le
Gestionnaire des tâches
(taskmgr.exe) ou la commande
PowerShell Get-Process. Quel
que soit le système d'exploitation,
la liste des processus est
maintenue par le noyau.

]]> 1.0 0.0 0 true true abc ps, ou top pour un suivi en temps réel

]]> On utilise par exemple ps aux
ou ps -ef pour obtenir la
liste complète des processus.
Pour un suivi interactif et
dynamique, on emploie plutôt
top ou htop.

]]> ls

]]> La commande ls sert à lister
le contenu d'un répertoire,
c'est-à-dire les fichiers, pas
les processus.

]]> cat

]]> La commande cat sert à
afficher le contenu d'un
fichier, et n'a aucun rapport
avec la liste des processus.

]]> grep

]]> La commande grep sert à
rechercher un motif dans un
texte, mais pas à lister les
processus en cours.

]]> Processus et système — Q10 : Démon Qu'appelle-t-on un démon sur un
système d'exploitation ?

]]> Sous Linux moderne, systemd est
le processus de démarrage (PID 1)
et gère tous les autres démons.
Sous macOS, ce rôle revient à
launchd. Sous Windows, on parle
de « services Windows ».

]]> 1.0 0.0 0 true true abc Une commande Unix particulière

]]> Un démon n'est pas une commande
mais un processus qui s'exécute
en arrière-plan.

]]> Un programme malveillant

]]> Le mot « démon » est ici un
terme technique sans connotation
négative. Il désigne un
processus particulier, et non
un logiciel malveillant.

]]> Un processus qui s'exécute en arrière-plan, sans interface utilisateur, généralement lancé au démarrage du système et fournissant un service comme un serveur web, une base de données ou un service de journalisation

]]> Les noms des démons se
terminent souvent par la lettre
« d » : httpd, sshd,
cron, systemd. Ils sont
visibles avec la commande ps,
mais aucun terminal ne leur est
associé.

]]> Un fichier caché du système

]]> Un démon est un processus, pas
un fichier. Le mot « caché »
renvoie ici à l'absence
d'interface utilisateur, pas à
un fichier sur le disque.

]]> Processus et système — Q11 : Course critique Qu'appelle-t-on une course critique
(parfois nommée race condition) ?

]]> La solution consiste à mettre en
place une synchronisation des
accès, par exemple à l'aide de
verrous, de sémaphores, ou de
transactions atomiques. Une
alternative consiste à éviter
toute donnée partagée, par exemple
en utilisant un échange par files
de messages.

]]> 1.0 0.0 0 true true abc Une optimisation utilisée par le compilateur

]]> Une course critique est un
défaut de programmation, pas
une optimisation.

]]> Une compétition sportive informatisée

]]> Cette interprétation littérale
est sans rapport avec le sens
technique de l'expression.

]]> Un phénomène sans rapport avec les fils d'exécution

]]> La course critique est
précisément un phénomène lié à
l'exécution concurrente de
plusieurs fils accédant à des
données partagées.

]]> Un bug qui survient lorsque l'ordre d'exécution de plusieurs fils d'exécution accédant à une même ressource partagée influence le résultat de manière imprévisible

]]> Exemple typique : deux fils
d'exécution incrémentent
simultanément la même variable.
Selon l'entrelacement des
opérations, le résultat varie.
Ces bugs sont particulièrement
difficiles à diagnostiquer car
ils sont souvent intermittents.

]]> Processus et système — Q12 : Verrou d'exclusion mutuelle À quoi sert un verrou d'exclusion
mutuelle ?

]]> Plusieurs variantes existent : les
sémaphores (qui généralisent le
verrou avec un compteur), les
verrous lecture-écriture (plusieurs
lecteurs simultanés autorisés, mais
un seul écrivain à la fois), et
les moniteurs (par exemple en
Java).

]]> 1.0 0.0 0 true true abc À stocker des données partagées

]]> Un verrou ne stocke pas de
données, il contrôle l'accès à
des données stockées par
ailleurs.

]]> À ralentir intentionnellement le programme

]]> Un verrou peut effectivement
ralentir le programme, mais ce
n'est pas son objectif. Son
rôle premier est de garantir la
cohérence des données
partagées.

]]> À chiffrer les données pour les protéger

]]> Le chiffrement relève de la
cryptographie, pas de la
synchronisation des fils
d'exécution.

]]> À garantir qu'un seul fil d'exécution à la fois accède à une ressource partagée, ce qui évite les courses critiques

]]> Le motif classique est le
suivant : on acquiert le verrou,
on effectue les opérations
critiques, puis on libère le
verrou. En Python, la syntaxe
with verrou: garantit la
libération même en cas
d'exception, ce qui est plus
sûr.

]]> Processus et système — Q13 : Interblocage Qu'appelle-t-on un interblocage ?

]]> Plusieurs stratégies de prévention
existent : ordonner systématiquement
les acquisitions de ressources
(toujours $A$ puis $B$),
utiliser des délais d'attente
(timeouts), détecter les
interblocages a posteriori (par
analyse des graphes d'attente), ou
les éviter avec des algorithmes
dédiés comme l'algorithme du
banquier de Dijkstra.

]]> 1.0 0.0 0 true true abc Un arrêt brutal du programme

]]> Un interblocage n'est pas un
arrêt brutal : les processus
impliqués restent actifs, mais
ils sont bloqués en attente
mutuelle. Aucun ne s'arrête de
lui-même.

]]> Un signal d'erreur émis par le système

]]> L'interblocage n'émet pas de
signal particulier. Au
contraire, il se manifeste par
un blocage silencieux que le
programmeur doit détecter
lui-même.

]]> Un blocage de l'écran

]]> Le mot peut faire penser à un
gel de l'affichage, mais le
sens technique en informatique
est tout autre. Il s'agit d'un
blocage logique entre
processus.

]]> Une situation dans laquelle plusieurs fils d'exécution ou processus s'attendent mutuellement sans fin, chacun détenant une ressource demandée par un autre

]]> Exemple : le fil $T_1$ détient
la ressource $A$ et attend $B$.
Le fil $T_2$ détient $B$ et
attend $A$. Aucun ne peut
progresser. Quatre conditions,
dites de Coffman, doivent être
réunies simultanément pour
qu'un interblocage se produise.

]]> Processus et système — Q14 : Communication entre processus Comment deux processus isolés
peuvent-ils communiquer entre eux ?

]]> Le choix du mécanisme dépend du
besoin : un tube convient pour un
simple flux ; une connexion
réseau, pour communiquer à
distance ; la mémoire partagée,
pour la performance ; une file de
messages, pour découpler le
producteur du consommateur.

]]> 1.0 0.0 0 true true abc Uniquement par le clavier

]]> Le clavier permet à un
utilisateur d'interagir avec
un programme, mais ce n'est
pas un mécanisme de
communication entre processus.

]]> Uniquement via Internet

]]> Internet permet bien la
communication entre processus
distants, mais ce n'est pas le
seul mécanisme. De nombreux
processus communiquent
localement, sans passer par
Internet.

]]> À l'aide de tubes de communication, de connexions réseau (sockets), de fichiers partagés, d'une mémoire partagée explicite, ou de files de messages

]]> Tous ces mécanismes sont
fournis par le système
d'exploitation. Le tube Unix,
symbolisé par la barre
verticale | dans
l'interpréteur de commandes,
est l'un des plus simples
d'usage. Les sockets servent
aux communications réseau, et
la mémoire partagée privilégie
la performance.

]]> Il leur est impossible de communiquer

]]> Plusieurs mécanismes
permettent au contraire à des
processus isolés de
communiquer, comme expliqué
dans la bonne réponse.

]]> Processus et système — Q15 : Création d'un processus Sur les systèmes Unix, l'appel système
fork permet de :

]]> Le motif classique sous Unix est
l'enchaînement fork puis exec :
on duplique le processus, puis on
remplace l'image mémoire de
l'enfant par un autre programme.
Le parent peut ensuite continuer
en parallèle ou attendre la fin
de l'enfant avec un appel à
wait.

]]> 1.0 0.0 0 true true abc Exécuter un nouveau programme depuis le processus courant

]]> Cette opération correspond à
l'appel système exec, qui
est souvent combiné avec
fork pour lancer un nouveau
programme dans un nouveau
processus.

]]> Terminer immédiatement le processus appelant

]]> La terminaison d'un processus
se fait avec un appel système
comme exit, et non avec
fork.

]]> Dupliquer le processus appelant : on obtient un processus parent et un processus enfant, qui partagent au départ le même code et la même mémoire

]]> Après l'appel à fork, on
distingue le parent et l'enfant
par la valeur renvoyée : la
fonction renvoie $0$ dans le
processus enfant, et le
numéro de l'enfant dans le
processus parent. Ce mécanisme
est fondamental sous Unix.

]]> Créer un nouveau fichier sur le disque

]]> La création d'un fichier
relève d'autres appels
système, comme open avec
l'option de création. L'appel
fork concerne les processus,
pas les fichiers.

]]> Processus et système — Q16 : Processus zombie Qu'appelle-t-on un processus zombie ?

]]> Pour éviter l'apparition de
processus zombies, le parent doit
appeler wait ou waitpid après
la création d'un processus
enfant. Sans cela, le processus
enfant reste dans l'état zombie
jusqu'à ce que le parent le
récupère explicitement.

]]> 1.0 0.0 0 true true abc Un processus terminé dont le code de retour n'a pas encore été récupéré par son parent. Il occupe encore une entrée dans la table des processus

]]> Cet état apparaît avec la
lettre Z dans la commande
ps. Il est normalement
éphémère. Une accumulation de
processus zombies traduit
souvent un bug : le parent ne
récupère pas le statut de ses
enfants. Si le parent meurt,
le processus de démarrage
(PID 1) « adopte » les
processus orphelins.

]]> Un processus dangereux pour le système

]]> Le mot « zombie » est ici un
terme technique sans
connotation négative. Il
désigne un état particulier
dans le cycle de vie d'un
processus.

]]> Un signal système particulier

]]> Le zombie n'est pas un signal
mais un état d'un processus.

]]> Un processus pris dans une boucle infinie

]]> Une boucle infinie correspond
à un processus qui consomme du
temps processeur sans
terminer. Le zombie est un
processus déjà terminé, dont
il reste seulement l'entrée
dans la table des processus.

]]> Processus et système — Q17 : Le verrou global de l'interpréteur Python Qu'est-ce que le verrou global de
l'interpréteur dans l'implémentation
principale de Python ?

]]> Ce verrou fait l'objet de débats
depuis longtemps. Python 3.13
introduit, en option, la
possibilité de l'enlever. Pour
les opérations d'entrées-sorties
(réseau, fichiers), les fils
d'exécution restent utiles, car
ils libèrent le verrou pendant
les attentes.

]]> 1.0 0.0 0 true true abc Un module standard de la bibliothèque Python

]]> Le verrou global de
l'interpréteur n'est pas un
module Python, mais un
mécanisme interne de
l'interpréteur lui-même.

]]> Une fonction de la bibliothèque standard

]]> Le verrou global est un
mécanisme interne de
l'interpréteur, pas une
fonction accessible au
programmeur.

]]> Un verrou interne à l'interpréteur qui garantit qu'un seul fil d'exécution Python à la fois exécute du bytecode, ce qui simplifie l'implémentation de l'interpréteur mais limite le parallélisme effectif sur le processeur

]]> Une conséquence pratique : pour
du calcul intensif sur le
processeur, mieux vaut
utiliser le module
multiprocessing (qui crée de
vrais processus séparés)
plutôt que threading, à
moins que le verrou ne soit
libéré pendant les attentes
(entrées-sorties, par
exemple).

]]> Un éditeur de texte particulier

]]> Le verrou global est une
notion interne au système
d'exécution de Python, sans
rapport avec les éditeurs de
texte.

]]> Processus et système — Q18 : Priorité d'un processus Pourquoi un système d'exploitation
attribue-t-il des priorités
différentes aux processus ?

]]> Les systèmes d'exploitation à
contraintes temps réel offrent
des garanties strictes sur la
priorité. Les systèmes
généralistes adoptent une
politique « au mieux », tout en
cherchant à maintenir une équité
globale entre les processus.

]]> 1.0 0.0 0 true true abc Aucune raison particulière

]]> La priorité joue un rôle
essentiel dans l'allocation
du temps processeur, comme
détaillé dans la bonne
réponse.

]]> Pour s'assurer que les processus importants (interactifs, système) reçoivent davantage de temps processeur que les processus moins prioritaires (calculs en arrière-plan)

]]> Une priorité élevée signifie
plus de temps processeur
alloué. Sous Linux, la
commande nice permet de
régler cette priorité (de
$-20$ à $19$ ; un nombre plus
grand signifie un processus
plus « gentil », c'est-à-dire
moins prioritaire).

]]> Pour des raisons de sécurité

]]> La sécurité est gérée par les
permissions et les
mécanismes d'isolation, pas
par les priorités, qui
concernent l'allocation du
temps processeur.

]]> Pour faire plaisir aux développeurs

]]> Les priorités obéissent à des
considérations techniques, pas
à des préférences
subjectives.

]]> Processus et système — Q19 : Lister les processus sous Windows Comment afficher les processus actifs
sur Windows ?

]]> Sur tous les systèmes
d'exploitation modernes, on peut
observer les processus, mesurer
leur consommation de ressources
et les terminer. Les outils
diffèrent, mais les fonctions
proposées sont équivalentes.

]]> 1.0 0.0 0 true true abc Avec le Gestionnaire des tâches (raccourci Ctrl + Maj + Échap), ou avec la commande PowerShell Get-Process

]]> Le Gestionnaire des tâches
offre une interface graphique
riche. En ligne de commande,
on dispose de tasklist
(commande historique) ou de
Get-Process dans
PowerShell.

]]> Avec la commande ps

]]> La commande ps est propre
aux systèmes Unix. Elle n'est
pas disponible nativement
sous Windows.

]]> Il est impossible d'observer les processus sous Windows

]]> Plusieurs outils permettent
au contraire d'observer les
processus, comme expliqué
dans la bonne réponse.

]]> En éteignant et en rallumant Windows

]]> Cette plaisanterie n'a pas
lieu d'être : éteindre le
système ne permet
évidemment pas d'observer
ses processus en cours.

]]> Processus et système — Q20 : Tracer les appels système Quelle commande Linux permet de tracer
les appels système effectués par un
programme ?

]]> Plusieurs variantes existent :
ltrace pour tracer les
appels aux bibliothèques, perf
pour le profilage de
performances, ou encore
dtrace sur les systèmes BSD
et macOS. Tous ces outils
permettent de mieux comprendre
le comportement effectif d'un
programme.

]]> 1.0 0.0 0 true true abc ls

]]> La commande ls liste le
contenu d'un répertoire ;
elle n'a rien à voir avec
le traçage des appels
système.

]]> grep

]]> La commande grep sert à
rechercher un motif dans un
texte ; elle n'a aucun
rapport avec le traçage des
appels système.

]]> top

]]> La commande top montre
l'utilisation des ressources
(processeur, mémoire) par les
processus, mais elle ne
permet pas de tracer les
appels système d'un
programme particulier.

]]> strace

]]> La commande strace
./mon_programme affiche
chaque appel système effectué
par le programme (open,
read, write, etc.). C'est
un outil très utile pour
comprendre ce qu'un programme
fait au niveau du système.

]]> Processus et système — Q21 : Conditions nécessaires à un interblocage Quelles sont les quatre conditions
nécessaires pour qu'un interblocage
puisse se produire (selon Coffman,
$1971$) ?

]]> Cette théorie classique permet
d'analyser tout système
concurrent et constitue un
contenu classique des cours sur
les systèmes d'exploitation.

]]> 1.0 0.0 0 true true abc La mémoire, le processeur, le disque et le réseau

]]> Ces éléments sont des types
de ressources, mais ils ne
constituent pas les
conditions de Coffman, qui
décrivent une situation
d'attente entre processus.

]]> Trois conditions seulement suffisent

]]> Il s'agit bien de quatre
conditions, qui doivent toutes
être réunies pour qu'un
interblocage se produise.

]]> Aucune condition particulière

]]> Un interblocage requiert au
contraire la conjonction de
plusieurs conditions
précises, comme expliqué
dans la bonne réponse.

]]> L'exclusion mutuelle, la détention et l'attente, la non-préemption et l'attente circulaire

]]> Casser une seule de ces
conditions suffit à éliminer
le risque d'interblocage.
Plusieurs stratégies sont
possibles : autoriser la
préemption (ce qui casse la
troisième condition), ou
ordonner globalement
l'acquisition des ressources
(ce qui casse la quatrième).

]]> Processus et système — Q22 : Réservoir de fils d'exécution Pourquoi utiliser un réservoir de
fils d'exécution plutôt que créer un
nouveau fil pour chaque tâche ?

]]> Une bonne pratique consiste à
dimensionner la taille du
réservoir en fonction du nombre
de cœurs disponibles si la
charge est principalement
processeur, ou plus largement si
la charge est dominée par les
entrées-sorties (cas où les
fils sont souvent en attente).

]]> 1.0 0.0 0 true true abc Pour économiser sur l'achat du clavier

]]> Cette interprétation littérale
n'a aucun rapport avec la
notion technique de
réservoir de fils
d'exécution.

]]> La création d'un fil d'exécution a un coût (allocation de mémoire, mise en place d'un contexte). Un réservoir réutilise un nombre fixe de fils pour de nombreuses tâches, ce qui réduit ce coût et limite le degré de concurrence

]]> Ce motif de conception est
courant dans les serveurs
web et dans le calcul
parallèle. En Python,
concurrent.futures.ThreadPoolExecutor
fournit un tel réservoir.
En Java, on dispose de
Executors.newFixedThreadPool(n).

]]> Il n'y a aucun avantage à utiliser un réservoir

]]> Le réservoir apporte des
gains importants en
performance et en stabilité,
comme expliqué dans la
bonne réponse.

]]> Pour avoir un nombre illimité de fils d'exécution

]]> Le réservoir vise au
contraire à limiter le
nombre de fils d'exécution
actifs, afin d'éviter la
surcharge du système.

]]> Processus et système — Q23 : Producteurs et consommateurs En quoi consiste le motif des
producteurs et consommateurs ?

]]> Plusieurs patrons classiques de
concurrence existent :
producteurs-consommateurs,
lecteurs-écrivains, le
problème des cinq philosophes,
la barrière de synchronisation.

]]> 1.0 0.0 0 true true abc Une optimisation de la mémoire

]]> Le motif des producteurs et
consommateurs concerne la
synchronisation et le
découplage entre tâches, et
non l'optimisation de la
mémoire.

]]> Il s'agit d'un patron dans lequel des producteurs déposent des éléments dans une file partagée (avec verrou) et des consommateurs retirent ces éléments pour les traiter. Cela permet de découpler la production de la consommation

]]> C'est un patron de conception
fondamental. En Python, la
classe queue.Queue fournit
une file synchronisée.
Lorsque la file est pleine,
le producteur attend ;
lorsqu'elle est vide, le
consommateur attend.

]]> Un patron sans intérêt pratique

]]> Ce motif est au contraire
omniprésent en programmation
concurrente, comme expliqué
dans la bonne réponse.

]]> C'est un motif d'achat-vente

]]> Ce motif est un patron de
conception en programmation
concurrente, sans rapport
avec le commerce.

]]> Processus et système — Q24 : Choisir entre multiprocessing et fils d'exécution Pour du calcul intensif en Python,
faut-il préférer les fils d'exécution
ou les processus ?

]]> Compromis : les fils d'exécution
sont légers et partagent la
mémoire, mais sont limités par
le verrou global. Les processus
offrent un véritable
parallélisme, mais leur
création et leur communication
ont un coût plus élevé.

]]> 1.0 0.0 0 true true abc Les processus, par exemple avec le module multiprocessing ou avec concurrent.futures.ProcessPoolExecutor, qui contournent le verrou global en utilisant de vrais processus séparés

]]> Pour des tâches dominées par
les entrées-sorties (réseau,
fichiers), les fils
d'exécution restent
adaptés. Pour du calcul
intensif sur le processeur,
mieux vaut passer par
plusieurs processus.

]]> Uniquement le module asyncio

]]> Le module asyncio est
conçu pour la concurrence
dominée par les
entrées-sorties, et non pour
le calcul intensif sur le
processeur.

]]> Aucune des deux solutions ne convient

]]> Les deux approches sont
utiles, chacune dans son
domaine, comme expliqué
dans la bonne réponse.

]]> Toujours les fils d'exécution

]]> En raison du verrou global
de l'interpréteur dans
l'implémentation principale
de Python, les fils
d'exécution ne parallélisent
pas le calcul effectif sur
le processeur. Mieux vaut
utiliser des processus.

]]> Processus et système — Q25 : Synthèse Parmi les affirmations suivantes sur
les processus et les fils d'exécution,
laquelle est fausse ?

]]> Le programmeur reste
responsable de la correction de
son code concurrent. Le système
d'exploitation fournit les
outils, mais c'est à
l'application d'en faire un
usage rigoureux pour garantir la
cohérence des données
partagées.

]]> 1.0 0.0 0 true true abc Plusieurs fils d'exécution d'un même processus partagent la mémoire

]]> Cette affirmation est
correcte. C'est même la
caractéristique majeure des
fils d'exécution.

]]> Un interblocage requiert la conjonction des quatre conditions de Coffman

]]> Cette affirmation est
correcte. Casser l'une de
ces quatre conditions suffit
à éviter l'interblocage.

]]> Une course critique est résolue automatiquement par le système d'exploitation

]]> Cette affirmation est fausse
(donc c'est la bonne
réponse). Le système
d'exploitation ne résout pas
les courses critiques. Il
revient au programmeur
d'utiliser des mécanismes de
synchronisation appropriés
(verrous, sémaphores, files
synchronisées) pour les
éviter.

]]> Un processus dispose de sa propre mémoire isolée

]]> Cette affirmation est
correcte. L'isolation de la
mémoire est précisément ce
qui distingue les processus
des fils d'exécution.

]]> Processus et système — Q26 : Appel système Qu'appelle-t-on un appel système
(system call) ?

]]> Sous Linux, on peut observer les
appels système d'un programme avec
strace. Les appels système sont
coûteux car ils provoquent un
changement de contexte. Les
bibliothèques standard les
regroupent souvent (par exemple,
bufferisation des écritures) pour
réduire leur nombre.

]]> 1.0 0.0 0 true true abc Une fonction interne au programme
utilisateur

]]> Erreur : un appel système n'est
pas une fonction interne au
programme. C'est précisément un
mécanisme par lequel le programme
sort de son espace propre pour
demander un service au noyau.

]]> Un appel téléphonique automatisé

]]> Erreur : ce terme n'a aucun
rapport avec la téléphonie. Il
désigne un mécanisme interne du
système d'exploitation.

]]> Un protocole de communication
réseau

]]> Erreur : un appel système est
local au système d'exploitation
d'une machine. La communication
réseau peut passer par des
appels système (par exemple
socket), mais elle n'est pas
elle-même un appel système.

]]> Une demande de service adressée
par un programme au noyau du
système d'exploitation, par
exemple pour ouvrir un fichier,
allouer de la mémoire, créer un
processus ou communiquer sur le
réseau

]]> Bonne réponse : les appels
système sont l'interface entre le
mode utilisateur (où s'exécutent
les programmes ordinaires) et le
mode noyau (où s'exécutent les
opérations privilégiées). Un
appel système provoque un
changement de contexte vers le
noyau, qui exécute la requête
puis rend la main au programme.
Exemples : open, read,
write, fork, exec.

]]> Processus et système — Q27 : Mémoire virtuelle Pourquoi les systèmes d'exploitation
modernes utilisent-ils la mémoire
virtuelle pour les processus ?

]]> Sans mémoire virtuelle, un processus
pourrait lire ou écrire dans la
mémoire d'un autre processus, ce
qui poserait des problèmes de
sécurité majeurs. Aussi, les
adresses utilisées dans le code
seraient liées à la position
effective en mémoire, ce qui
compliquerait fortement la
compilation et le chargement de
programmes.

]]> 1.0 0.0 0 true true abc Pour économiser de l'électricité

]]> Erreur : la mémoire virtuelle
n'a pas pour objectif principal
la réduction de la consommation
électrique. Son rôle premier
est l'isolation et la flexibilité
de gestion mémoire.

]]> Parce que la mémoire physique
n'existe plus dans les
ordinateurs modernes

]]> Erreur : la mémoire physique
existe bel et bien dans tout
ordinateur ; c'est elle qui
stocke les données réellement.
La mémoire virtuelle est une
abstraction logicielle au-dessus
de la mémoire physique.

]]> Pour donner à chaque processus
l'illusion d'un espace mémoire
contigu et privé, en mappant les
adresses virtuelles utilisées par
le processus sur des adresses
physiques réelles ; cela permet
aussi l'isolation entre processus
et la possibilité de gérer plus
de mémoire que la mémoire physique
disponible (via le swap)

]]> Bonne réponse : la mémoire
virtuelle est l'un des piliers
des systèmes d'exploitation
modernes. Avantages : isolation
(un processus ne peut pas écrire
dans la mémoire d'un autre),
flexibilité (la mémoire physique
peut être fragmentée), illusion
d'abondance (le système peut
déborder sur le disque dur via
le swap). Inconvénient : un
léger surcoût lié à la
traduction d'adresses, mitigé
par des composants matériels
dédiés (TLB).

]]> Pour rendre les programmes plus
rapides à coder

]]> Erreur : la mémoire virtuelle
n'a pas d'effet direct sur la
rapidité de développement.
Elle simplifie certains
aspects, mais ce n'est pas son
motif principal.

]]>