Partie 5 - Threads¶
Support présentationIntroduction¶
Un thread (fil d’exécution), ou processus léger, est une unité d’exécution légère à l’intérieur d’un processus. Contrairement aux processus, les threads d’un même programme partagent la même mémoire (code, données, heap), mais disposent de leur propre stack (pile) et compteur ordinal (registre du processeur qui contient l’adresse mémoire de la prochaine instruction à exécuter).
Processus : unité lourde, isolée, avec espace mémoire séparé
Threads : unités légères, partagent la mémoire, plus rapides à créer et à communiquer
Avantages :
Partage facile de données (même mémoire)
Création et destruction plus rapides qu’un processus
Communication plus simple (pas besoin de mécanismes IPC lourds, voir chapitre IPC)
Inconvénients :
Risques de data race (accès concurrent non synchronisé)
Synchronisation nécessaire (mutex, sémaphores, …)
Un crash d’un thread peut faire planter tout le processus
Cas d’utilisation de threads :
Serveurs web multi-clients : chaque requête HTTP peut être gérée par un thread, avec partage du cache et des données globales.
Applications interactives : séparer l’interface utilisateur (UI) et le traitement lourd pour éviter le blocage (ex. un éditeur ou un jeu vidéo).
Calcul parallèle : diviser un gros calcul en plusieurs tâches parallèles sur des cœurs différents.
Producteur / consommateur : un thread lit des données (entrée clavier, socket réseau, fichier) pendant qu’un autre les traite.
Simulations : gestion de plusieurs entités indépendantes (ex. particules, joueurs dans un jeu en réseau).
Avec les systèmes Unix, nous disposons de deux types de threads :
les pthreads, pour POSIX thread, définis dans
<pthread.h>, pour les systèmes Unix, que nous utiliserons dans ce coursles threads, donnés par l’API C11, définis dans
<threads.h>, plus portable
Dans les deux cas, le thread commence à s’exécuter à sa construction avec create. Il prend en entrée une variable qui contiendra le thread (utilisée principalement pour attendre celle-ci par la suite), un pointeur sur fonction et des arguments.
Le fil principal pourra attendre la fin du thread avec join, s’il n’y a pas de join il n’est pas garanti que le thread aura le temps de finir son execution.
La signature du pointeur sur fonction des pthreads est void *(*) (void *) (fonction qui prend en entrée un void * et retourne un void *), pour les threads de l’API C11, la signature est int(*) (void*) (fonction qui prend en entrée un void * et retourne un int).
Les threads ne peuvent donc prendre en entrée qu’un seul argument de type void *, pour passer plusieurs arguments il faut donc passer par une structure.
Il faudra faire attention si des éléments dans la structure peuvent sortir de portée avant la fin de celui-ci. Par exemple, avoir un attribut char * nom dans la structure où le malloc est fait dans le fil principal, puis la structure est passée au thread avant de faire un free sur nom dans la boucle principale avant la fin du thread. Ce genre d’information doit être clairement documentée dans le code (qui libère la mémoire).
Pour le type de retour, les pthreads retournent ce qu’ils veulent (void *) et les threads uniquement un int.
POSIX threads¶
L’API standard sous Linux est Pthreads (POSIX threads), disponible avec l’en-tête <pthread.h> (voir man 7 pthreads).
Pour la compilation, il ne faut pas oublier d’ajouter -pthread aux flags :
gcc -std=c2x -Wall -Wextra -pedantic threads.c -o threads -pthread
La création se fait avec pthread_create :
int pthread_create(pthread_t *thread,
const pthread_attr_t *attr,
void *(*start_routine)(void *),
void *arg);
thread: pointeur où sera stocké l’identifiant du threadattr: attributs du thread (souventNULL)start_routine: fonction exécutée par le threadarg: argument passé à cette fonction
L’attente du thread se fait avec pthread_join :
int pthread_join(pthread_t thread, void **retval);
thread: l’identifiant du threadretval: la valeur retournée par le thread (NULLsi aucune valeur)
Le fil principal attendra la fin du thread au niveau de cette fonction tant que le thread n’aura pas terminé son calcul.
Si un pthread veut retourner une valeur, il peut utiliser pthread_exit à la fin de sa fonction :
void pthread_exit(void *retval);
Exemple sans retour de valeur :
1 #include <pthread.h>
2 #include <stdio.h>
3 #include <stdlib.h>
4
5 void *ma_fonction(void *arg) {
6 int *val = (int *)arg;
7 printf("Hello depuis le thread, arg = %d\n", *val);
8 return NULL;
9 }
10
11 int main(void) {
12 pthread_t tid;
13 int valeur = 42;
14
15 if (pthread_create(&tid, NULL, ma_fonction, &valeur) != 0) {
16 perror("pthread_create");
17 exit(EXIT_FAILURE);
18 }
19
20 // attendre la fin du thread
21 pthread_join(tid, NULL);
22
23 printf("Thread terminé !\n");
24 return EXIT_SUCCESS;
25 }
Exemple partiel avec une valeur retournée :
void *ma_fonction(void *arg) {
int *res = malloc(sizeof(int));
*res = 1234;
pthread_exit(res);
}
// main ...
int *resultat;
pthread_join(tid, (void **)&resultat);
printf("Résultat : %d\n", *resultat);
free(resultat);
Synchronisation¶
Comme plusieurs threads partagent les mêmes variables globales ou les données du tas (heap), il faut éviter les accès concurrents non contrôlés. Sinon, on obtient des résultats incohérents : c’est le problème des race conditions (« conditions de compétition ») ou data race (course aux données, présenté ci-dessous).
Exemple classique : incrémenter une variable globale depuis deux threads.
1#include <pthread.h>
2#include <stdio.h>
3
4int compteur = 0;
5
6void *incremente(void *arg) {
7 (void)arg;
8 for (int i = 0; i < 1000000; i++) {
9 compteur++;
10 }
11 return NULL;
12}
13
14int main(void) {
15 pthread_t t1, t2;
16 pthread_create(&t1, NULL, incremente, NULL);
17 pthread_create(&t2, NULL, incremente, NULL);
18
19 pthread_join(t1, NULL);
20 pthread_join(t2, NULL);
21
22 printf("Compteur final = %d\n", compteur);
23 return 0;
24}
Résultats observés (variables d’une exécution à l’autre) :
Compteur final = 1048495
Compteur final = 1102100
Compteur final = 1069216
Compteur final = 1087636
alors que le résultat attendu est 2 000 000 (chaque thread fait 1 000 000 incréments).
Pourquoi ce bug ?¶
L’opération compteur++ n’est pas atomique, elle se décompose en plusieurs instructions machine :
Lire la valeur actuelle de
compteurAjouter 1
Réécrire la nouvelle valeur dans
compteur
Si deux threads exécutent cette séquence en même temps, ils peuvent interférer :
Exemple :
compteur = 50Thread t1 lit
50Thread t2 lit aussi
50(presque en même temps)t1 calcule
50+1 = 51et écrit51t2 calcule
50+1 = 51et écrit aussi51
Résultat final, compteur = 51, alors qu’on aurait dû avoir compteur = 52.
Ce phénomène se produit des millions de fois dans la boucle, expliquant pourquoi le résultat final varie et est toujours inférieur à 2000000.
Solution : utiliser des mécanismes de synchronisation (mutex, opérations atomiques, etc.) pour rendre l’incrément atomique.
Mutex¶
Un mutex (mutual exclusion - verrou d’exclusion mutuelle) est un verrou qui garantit qu’un seul thread accède à une section critique à la fois.
Avec les pthreads, le mutex est un pthread_mutex_t qui peut être initialisé statiquement ou dynamiquement :
Initialisation statique :
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;Initialisation dynamique :
pthread_mutex_init(&m, NULL);Libération (si init dynamique) :
pthread_mutex_destroy(&m);
Il peut ensuite être utilisé en le verrouillant avec pthread_mutex_lock avant la zone critique puis en le déverrouillant avec pthread_mutex_unlock après la zone critique.
Si un thread essaie d’appeler pthread_mutex_lock sur un verrou déjà verrouillé, il est mit en attente jusqu’à ce que le mutex soit déverrouillé.
Exemple :
1 #include <pthread.h>
2 #include <stdio.h>
3
4 pthread_mutex_t verrou = PTHREAD_MUTEX_INITIALIZER;
5 int compteur = 0;
6
7 void *incremente(void *arg) {
8 (void)arg;
9 for (int i = 0; i < 1000000; i++) {
10 pthread_mutex_lock(&verrou);
11 compteur++;
12 pthread_mutex_unlock(&verrou);
13 }
14 return NULL;
15 }
16
17 int main(void) {
18 pthread_t t1, t2;
19 pthread_create(&t1, NULL, incremente, NULL);
20 pthread_create(&t2, NULL, incremente, NULL);
21
22 pthread_join(t1, NULL);
23 pthread_join(t2, NULL);
24
25 printf("Compteur final = %d\n", compteur);
26 return 0;
27 }
Grâce au mutex, il n’y a plus de problèmes de data race (accès concurrent non synchronisé) et le compteur est bien à 2000000 en fin de calcul.
Il est aussi possible de mettre le mutex dans une structure qui accompagnera la donnée critique.