DUT Informatique

Module Système S4-L

2010 / 2011
Orsay
Travaux Dirigés no 5 : Threads

Objectifs : apprendre à créer, travailler avec et arrêter des threads (ou proces-
sus légers). Savoir reconnaître les données partagées entre différents threads.
Être capable d’orchestrer la synchronisation de threads au moyen des primi-
tives de terminaison ou de sémaphores d’exclusion mutuelle.

1 Notes de cours
1.1 Rappels sur le contexte d’un processus
Le contexte d’un processus est l’ensemble des structures de données nécessaires au système
pour assurer le contrôle de ce processus. Elles se répartissent en deux catégories :
1. Structures dédiées au contrôle des ressources :
– Masque de création des fichiers (umask) qui spécifie les bits de permission à exclure
lors de la création de fichiers ou répertoires.
– Propriétaires et groupes propriétaires réels (correspondant à celui qui a demandé la
création du processus) et effectifs (qui détermine les droits du processus par rapport
aux fichiers du système, souvent identité du propriétaire du fichier contenant le binaire
exécuté).
– Liste des descripteurs des fichiers ouverts.
– Répertoire de travail.
– Implantation en mémoire des données et du programme, qui comprend le segment
de code ou text segment (le code objet et exécutable du programme), le segment de
données ou data segment (les variables globales et static), et le tas ou heap segment
(la mémoire allouée dynamiquement par malloc()).
2. Structures dédiées à l’exécution du processus :
– Informations nécessaires à l’ordonnanceur (priorité, politique d’ordonnancement...).
– Valeur des registres, en particulier le compteur ordinal.
– Informations relatives aux signaux.
– Pile d’exécution ou stack segment (contenant la pile des appels de fonction, les argu-
ments et les variables locales).

1.2 Threads
La création d’un nouveau processus par la primitive fork() nécessite la copie complète du
contexte du processus père. Cela a l’avantage de la simplicité mais est d’une part particu-
lièrement coûteux en temps d’exécution pour le système et d’autre part pas toujours adapté
aux applications avec beaucoup de parallélisme. Les threads, qu’on appelle aussi processus
légers ou activités, sont des unités d’exécution des processus : ils travaillent directement avec
les structures de données dédiées au contrôle (voir Section 1.1, catégorie 1) du processus père,
qu’on appellera plus justement activité initiale. Leur temps de création est minimal pour le
Travaux Dirigés no 5 Threads 2/7

système (qui n’a plus besoin que de copier les structures de données dédiées à l’exécution, voir
Section 1.1, catégorie 2). Cependant leur manipulation est plus délicate pour les programmeurs
qui doivent être parfaitement conscients des problèmes liés au travail en mémoire partagée et à
l’aise avec les solutions telles que les sémaphores d’exclusion mutuelle.

En particulier, on notera que le code, les variables globales et la mémoire allouée dynami-
quement sont partagés entre les différentes activités d’un même processus. De même, bien
qu’elle ne soit connue directement que d’une activité, une variable locale dans la pile d’une
activité peut être lue ou modifiée par une autre activité si elle en connaît l’adresse.

1.2.1 Création
# i n c l u d e < p t h r e a d . h>
int pthread_create (
pthread_t ∗ p_tid , /∗ P o i n t e u r s u r i d e n t i t e du t h r e a d ∗ /
pthread_attr_t ∗ p_attr , /∗ NULL : a t t r i b u t s p a r d e f a u t ∗ /
void ∗ (∗ f o n c t i o n ) ( void ∗ ar g ) , / ∗ F onct i on e x e c u t e e par l e t h r e a d ∗ /
void ∗ ar g /∗ P a r a m e t r e de << f o n c t i o n >> ∗ /
);

La primitive pthread_create crée une nouvelle activié et renvoie son identité à l’adresse
p_tid (il s’agît d’un numéro entier non signé qui servira par la suite à la gestion du thread).
Son argument attr définit les attributs du thread (nous utiliserons toujours NULL, qui donne les
attributs par défaut), fonction est un pointeur sur la fonction qui sera exécutée par l’activité
(cette fonction retourne nécessairement un void * et prend nécessairement un unique argu-
ment de type void *). Enfin, le dernier argument arg correspond à l’argument transmis à la
fonction fonction. Cette primitive retourne 0 en cas de succès, un code d’erreur sinon.

1.2.2 Identité
Chaque processus a un numéro unique, le pid, qui est renvoyé par la primitive getpid().
Tout processus est lui-même décomposé en threads qui ont chacun leur identifiant unique pour
un même processus, le tid. On notera l’activité tid (par exemple 5) du processus pid (par
exemple 1234) sous la forme pid.tid (par exemple 1234.5). Deux primitives sont dédiées à
la manipulation des identités des activités :

# i n c l u d e < p t h r e a d . h>
p t h r e a d _ t p t h r e a d _ s e l f ( void ) ;
int pthread_equal ( pthread_t tid_1 , pthread_t tid_2 ) ;

1. pthread_self() retourne l’identificateur du thread courant dans le processus courant

(le tid).
2. pthread_equal(tid_1,tid_2) retourne 0 si les deux identités transmises en argument
sont identiques et une valeur non nulle sinon.

1.2.3 Terminaison
Tous les threads d’un même processus prennent fin si l’activité initiale prend fin ou si une des
activités fait appel à la primitive exit() (ou _exit()). Une activité seule prend fin automati-
quement quand la fonction passée en argument de la primitive pthread_create retourne. Les
ressources allouées pour une activité ne sont jamais libérées automatiquement. Les primitives

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L

Travaux Dirigés no 5 Threads 3/7

de terminaison d’un thread (sans affecter les autres activités) et de libération de ses ressources
sont les suivantes :
# i n c l u d e < p t h r e a d . h>
void p t h r e a d _ e x i t ( void ∗ p _ s t a t u s ) ;
int pthread_detach ( pthread_t t id ) ;

1. pthread_exit(p_status) termine l’activité qui l’a appelée en indiquant une valeur de

retour à l’adresse p_status. Cette primitive ne peut jamais retourner dans le thread qui
l’a appelée.
2. pthread_detach(tid) indique au système qu’il pourra récupérer les ressources al-
louées au thread d’identifiant tid lorsqu’il terminera ou qu’il peut récupérer les res-
sources s’il est déjà terminé. Cette primitive ne provoque pas la terminaison du thread
appelant. Elle retourne 0 en cas de succès, un code d’erreur sinon.

1.2.4 Synchronisation
Les threads disposent dans les grandes lignes des mêmes outils de synchronisation que les pro-
cessus. Le premier d’entre eux est l’attente passive de la fin d’une autre activité qui rappelle
les primitives wait() ou waitpid() liées aux processus. La primitive permettant ce compor-
tement est la suivante :
# i n c l u d e < p t h r e a d . h>
i n t p t h r e a d _ j o i n ( p t h r e a d _ t t i d , v o i d ∗∗ s t a t u s ) ;

Cette primitive suspend l’exécution de l’activité appelante jusqu’à la fin de l’activité d’iden-
tifiant tid. Si l’activité d’identifiant tid est déjà terminée, cette primitive retourne immédia-
tement. En cas de succès, elle retourne 0 et place à l’adresse *status la valeur de retour de
l’activité attendue. En cas d’echec elle retourne un code d’erreur.

L’autre principal outil de synchronisation entre threads est le sémaphore d’exclusion mutuelle.
On manipule les sémaphores pour les threads à l’aide des quatres primitives fondamentales
suivantes qui retournent toutes 0 en cas de succès et un code d’erreur sinon :

# i n c l u d e < p t h r e a d . h>
i n t p t h r e a d _ m u t e x _ i n i t ( p t h r e a d _ m u t e x _ t ∗ p_mutex , NULL ) ;
i n t p t h r e a d _ m u t e x _ l o c k ( p t h r e a d _ m u t e x _ t ∗ p_mutex ) ;
i n t p t h r e a d _ m u t e x _ u n l o c k ( p t h r e a d _ m u t e x _ t ∗ p_mutex ) ;
i n t p t h r e a d _ m u t e x _ d e s t r o y ( p t h r e a d _ m u t e x _ t ∗ p_mutex ) ;

1. pthread_mutex_init(p_mutex,NULL) réalise l’initialisation d’un sémaphore d’exclu-

sion mutuelle de type pthread_mutex_t dont on aura passé l’adresse en premier argu-
ment. Le second argument indique les attributs du sémaphore, on indiquera NULL pour
avoir les attributs par défaut qui initialisent le sémaphore avec un droit (le sémaphore
n’est pas bloqué).
2. pthread_mutex_lock(p_mutex) réalise l’opération P (demande d’un droit) sur le sé-
maphore dont l’adresse est passée en argument.
3. pthread_mutex_unlock(p_mutex) réalise l’opération V (restitution d’un droit) sur le
sémaphore dont l’adresse est passée en argument.
4. pthread_mutex_destroy(p_mutex) rend le sémaphore dont l’adresse est passée en ar-
gument inutilisable à moins d’un nouvel appel à pthread_mutex_init(p_mutex,NULL).

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L

Travaux Dirigés no 5 Threads 4/7

2 Exercices
2.1 Exercice 1 : partage des données et terminaison
On considère le code suivant où plusieurs threads sont crées, chacun ayant pour unique travail
d’afficher son identité :

# i n c l u d e < s t d i o . h>
# i n c l u d e < s t d l i b . h>
# i n c l u d e < p t h r e a d . h>

# d e f i n e NB_THREADS 3

int thread_execute = 0;
p t h r e a d _ t t i d [NB_THREADS ] ;

/ ∗ F o n c t i o n e x e c u t e e p a r l e s t h r e a d s . Le t y p e de r e t o u r e t l ’ a r g u m en t s o n t
∗ o b l i g a t o i r e m e n t de t y p e v o i d ∗ , ce q u i n e c e s s i t e s o u v e n t d e s c a s t s .
∗/
void ∗ f o n c t i o n ( void ∗ i ) {
i n t n = ∗ ( ( i n t ∗) i ) ;
p r i n t f ( " T h r ead numero %d , i d e n t i t e %d.%u \ n " , n , g e t p i d ( ) , p t h r e a d _ s e l f ( ) ) ;
thread_execute = 1;
}

i n t main ( ) {
int i ;
/ ∗ B o u c l e de c r e a t i o n d e s t h r e a d s . ∗ /
f o r ( i = 0 ; i <NB_THREADS ; i ++) {
i f ( p t h r e a d _ c r e a t e (& t i d [ i ] , NULL, f o n c t i o n , ( v o i d ∗)& i ) == −1) {
f p r i n t f ( s t d e r r , " E r r e u r c r e a t i o n t h r e a d numero %d . \ n " , i ) ;
exit (1);
}
}
p r i n t f ( " T h r ead i n i t i a l d ’ i d e n t i t e %d .%u \ n " , g e t p i d ( ) , p t h r e a d _ s e l f ( ) ) ;
i f ( thread_execute )
p r i n t f ( " Des t h r e a d s a n n e x e s o n t e t e e x e c u t e s . \ n " ) ;
else
p r i n t f ( " Aucun t h r e a d an n ex e n ’ a e t e e x e c u t e . \ n " ) ;
return 0;
}

Questions :
1. Combien au maximum, avec ce programme, y-a-t-il de threads s’exécutant en parallèle
(ou en concurrence s’il n’y a pas assez de ressources) ?
2. Listez toutes les variables et dire par quels threads elles sont directement utilisables.
3. Comment un thread pourrait lire ou modifier la variable n d’un autre thread ?
4. Expliquez le résultat d’exécution suivant où le numéro de chaque thread est le même.
Proposez une solution.
Thread numero 3, identite 13033.3084860304
Thread numero 3, identite 13033.3076467600
Thread numero 3, identite 13033.3068074896
Thread initial d’identite 13033.3084863168
Des threads annexes ont ete executes.
5. Expliquez le résultat d’exécution suivant où aucun thread n’a réalisé son affichage. Pro-
posez une solution.
Thread initial d’identite 13433.3084601024
Aucun thread annexe n’a ete execute.

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L

Travaux Dirigés no 5 Threads 5/7

2.2 Exercice 2 : parallélisation de la multiplication matrice × vecteur

L’opération de multiplication d’une matrice par un vecteur est l’une des plus utiles en infor-
matique (calcul scientifique, infographie...). Il est très intéressant de la paralléliser pour en
améliorer la performance. Elle est réalisée simplement par les deux boucles montrées en Fi-
gure 1 où on voit comment le vecteur résultat y est calculé à partir de la matrice A et du vecteur
x. Plus précisément, on voit que le ième élément du vecteur y est calculé à partir seulement de
la ième ligne de la matrice A et de tout le vecteur x. Puisque A et x restent constants, on peut
calculer chaque élément du vecteur y indépendamment les uns des autres.
Proposez un programme utilisant les threads pour le calcul du vecteur y tel que chaque élément
de ce vecteur soit calculé en parallèle par rapport aux autres.

(*)

(i,*)
(i)
for (i=0; i<NB_LIGNES; i++)
for (j=0; j<NB_COLONNES; j++) . =
y[i] += A[i][j] * x[j];

A x y
F IGURE 1 – Noyau de la multiplication matrice × vecteur

2.3 Exercice 3 : synchronisation de threads

Le but de cet exercice est d’écrire un programme dans lequel le thread initial et un thread
annexe, chacun de leur côté, incrémentent une variable partagée initialisée à 0. Le thread ini-
tial affiche la valeur finale de la variable partagée avant de terminer. Discutez les risques d’un
manque de synchronisation dans un tel programme. Écrivez un programme réalisant ces opé-
rations de manière sûre (avec les synchronisations adéquates).

2.4 Exercice 4 : client-serveur

On désire simuler un mécanisme client-serveur de réservation de places. Il y a 100 places qui
sont représentées par un tableau place de 100 entiers. place[i] vaut 0 si la place est libre et
vaut la valeur du numéro du client sinon. Les requêtes des clients sont reçues au clavier par le
thread initial du serveur qui attend la frappe d’un entier. Si cet entier est supérieur ou égal à 0,
il indique le nombre de places demandées par le client, sinon il indique l’arrêt des demandes
de réservation et provoque l’affichage final du tableau de places. Après chaque demande de
réservation, le thread initial créera un thread annexe pour traiter la demande et se remettra en
attente d’une nouvelle requête. Les clients sont numérotés par ordre d’arrivée.
Implantez un programme respectant cette spécification. Vous veillerez en particulier à mettre
en place les synchronisations nécessaires.

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L

Travaux Dirigés no 5 Threads 6/7

3 Entraînement : exercice corrigé

3.1 Énoncé : le nombre fuyant
On cherche à implanter un jeu de « nombre mystère fuyant ». Il s’agît d’une variante du jeu
du nombre mystère où l’ordinateur choisit un nombre entier aléatoirement et ne répond aux
propositions d’un joueur que par Trop petit !, Trop grand ! ou Gagné !. Dans cette variante,
toutes les t secondes l’ordinateur change le nombre mystère en lui ajoutant ou en lui retirant
un nombre x. Le joueur en est informé par un message (par exemple : Le nombre mystère a
été augmenté de 13 !). Les nombres t et x sont définis aléatoirement et changent à chaque
fois qu’on les utilise (par exemple après 5 secondes de jeu l’ordinateur ajoute 32 au nombre
mystère, puis au bout de 11 secondes, il lui retire 13, etc.). Le joueur n’aura de plus qu’un
temps limité pour trouver le nombre fuyant.
Réalisez l’application implantant le jeu du nombre fuyant à l’aide de trois threads. Le thread
initial réalisera le jeu du nombre mystère classique. Un premier thread annexe se chargera
des modifications du nombre mystère dans le temps. Un second thread annexe se chargera du
respect du temps limite. Pour l’implantation, le nombre mystère sera choisi entre 0 et 200, t
entre 5 et 10, x entre 0 et 50 sera ajouté ou retiré (choix aléatoire) avec la contrainte de préserver
le nombre mystère entre 0 et 200, enfin, le temps limite sera de 40 secondes.

Note : pour les temporisations, utilisez seulement des primitives sleep(). L’utilisation du si-
gnal SIGALRM est possible (c’est d’ailleurs ce que fait sleep()) puisque les informations sur
les signaux sont liées aux threads et non au processus. Cependant il n’est pas possible d’uti-
liser la primitive signal() qui ne fonctionne pas comme elle le devrait avec les threads (elle
s’applique à tous les threads d’un même processus). À la place il faudrait utiliser la primitive
sigaction() qui n’est pas au programme (voir pages de man pour les curieux !).

3.2 Correction (essayez d’abord ! ! !)

Le programme est relativement simple : il faut commencer par écrire le code du jeu du nombre
mystère habituel. Ensuite on intègre un premier thread simple pour le temps maximal du jeu.
Quand le temps maximum est arrivé, ce thread peut quitter tout le programme par un appel à la
primitive exit(). Enfin on ajoute la dimension « fuyante » par un nouveau thread. Le besoin
en synchronisation est centré sur le nombre mystère. On utilise un sémaphore d’exclusion
mutuelle pour assurer qu’un seul thread pourra accéder en lecture comme en écriture au nombre
mystère (le thread initial doit tester si la proposition du joueur est correcte -accès en lecture-,
et le thread annexe modifie ce nombre -accès en écriture-). Lorsque le joueur a gagné, le thread
initial termine, mettant ainsi immédiatement fin aux autres activités.

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L

Travaux Dirigés no 5 Threads 7/7

# i n c l u d e < s t d i o . h>
# i n c l u d e < s t d l i b . h>
# i n c l u d e < p t h r e a d . h>

# define N_INF 0
# define N_SUP 200
# define X_MAX 50
# define T_INF 5
# define T_SUP 10
# define TIMEOUT 40

in t mystere ; / ∗ Nombre m y s t e r e ∗ /
p t h r e a d _ m u t e x _ t mutex ; / ∗ Semaphore de p r o t e c t i o n ∗ /

void ∗ fuyeur ( ) { / ∗ F o n c t i o n du t h r e a d f u y e u r ∗ /
int t , x ;
while ( 1 ) {
t = r a n d ( ) % ( T_SUP − T_INF + 1 ) + T_INF ; / ∗ Temps d ’ a t t e n t e ∗ /
x = r a n d ( ) % (X_MAX + 1 ) ; /∗ Modification ∗/
sleep ( t ) ;
p t h r e a d _ m u t e x _ l o c k (& mutex ) ; /∗ P r otection modification ∗/
i f ( rand ()%2) { / ∗ On a j o u t e ou on r e t i r e ∗ /
p r i n t f ( " Le nombre m y s t e r e a e t e au g m en te de %d ! \ n " , x ) ;
m y s t e r e = ( ( m y s t e r e + x ) > N_SUP ) ? N_SUP : m y s t e r e + x ;
}
else {
p r i n t f ( " Le nombre m y s t e r e a e t e d i m i n u e de %d ! \ n " , x ) ;
m y s t e r e = ( ( m y s t e r e − x ) < N_INF ) ? N_INF : m y s t e r e − x ;
}
p t h r e a d _ m u t e x _ u n l o c k (& mutex ) ; / ∗ F in de p r o t e c t i o n ∗ /
}
}

void ∗ timeout ( ) { / ∗ F o n c t i o n du t h r e a d t i m e o u t ∗ /
s l e e p ( TIMEOUT) ;
p r i n t f ( " Temps e c o u l e ! P er d u ! \ n " ) ;
exit (1); /∗ e x i t ( ) termine t ou t ∗/
}

i n t main ( i n t a r g c , char ∗ a r g v [ ] ) {
i n t p r o p o s i t i o n = N_INF − 1 ;
p t h r e a d _ t t1 , t 2 ;

srand ( getpid ( ) ) ; /∗ I n i t i a l i s a t i o n generateur ∗/

p t h r e a d _ m u t e x _ i n i t (& mutex , NULL ) ; / ∗ I n i t i a l i s a t i o n du s em a p h o r e ∗ /
m y s t e r e = r a n d ( ) % (N_SUP−N_INF +1 ) + N_INF ; / ∗ I n i t i a l i s a t i o n du nb m y s t e r e ∗ /

p t h r e a d _ c r e a t e (& t1 , NULL, f u y e u r , NULL ) ; / ∗ L a n cem en t d e s t h r e a d s ∗ /

p t h r e a d _ c r e a t e (& t2 , NULL, t i m e o u t , NULL ) ;

/ ∗ Jeu c l a s s i q u e du nombre m y s t e r e ∗ /
p t h r e a d _ m u t e x _ l o c k (& mutex ) ; / ∗ P r o t e c t i o n du t e s t du w h i l e ∗ /
while ( p r o p o s i t i o n != m ys tere ) {
p t h r e a d _ m u t e x _ u n l o c k (& mutex ) ; / ∗ F in de p r o t e c t i o n du t e s t ∗ /
p r i n t f ( " Proposition ?\ n" ) ;
s c a n f ( " %d " ,& p r o p o s i t i o n ) ;
i f ( pro p os i t i on > mystere )
p r i n t f ( " Trop g r a n d ! \ n " ) ;
else {
i f ( p ro po s i ti o n < mystere )
p r i n t f ( " Trop p e t i t ! \ n " ) ;
else
break ;
}
p t h r e a d _ m u t e x _ l o c k (& mutex ) ; / ∗ P r o t e c t i o n du t e s t ∗ /
}
p r i n t f ( " Gagne ! \ n " ) ;
return 0;
}

IUT d’Orsay – DUT Informatique 2010 / 2011 Module Système S4-L