Threads

Exercice : gestion des impressions

1. Un thread par impression

On reprend le programme imprime0.c évoqué dans les exercices sur les communications et synchronisations entre processus. On souhaite modifier ce programme pour que le thread principal crée, chaque impression, un thread chargé de l'impression. Vérifier que:

• plusieurs threads peuvent s'exécuter en même temps;
• chaque thread imprime un fichier différent du thread voisin.
• Remarque: pour simplifier, il est possible de limiter le nombre total d'impressions.

Visualisez les différents threads avec la commande ps (pour afficher les différents threads: ps -m ou ps -L selon les versions).

2. Synchronisation autour de l'imprimante

Reprendre le programme précédent pour que les threads ne mélangent pas leurs impressions à l'imprimante.

Question (de réflexion) 2.1: synchronisation

Quel est le type de synchronisation à mettre en place entre les threads chargés de l'impression?

Question 2.2: implantation

Implanter avec un mutex de la bibliothèque POSIX thread.

3. Utilisation d'une zone tampon circulaire

On ne crée plus un thread à chaque demande d'impressions. On crée au préalable un ensemble de threads de taille MAXNBTHREADS = 3 threads. Chaque thread se met en attente d'une impression, imprime puis se met en attente d'une nouvelle impression. De plus, une zone tampon circulaire contenant de taille MAXNBIMPRESSIONS = 5 est utilisée pour stocker la file d'impressions. L'accès à l'imprimante reste exclusif.

Question (de réflexion) 3.1: synchronisation

Quel est le type de synchronisation à mettre en place entre le thread principal et les autres threads?

Écrire l'algorithme sur papier.

Question 3.2: implantation avec sémaphores

Écrire ce programme en utilisant des sémaphores POSIX.

Question 3.3: implantation avec conditions

Écrire ce programme en utilisant des conditions.

4. Terminaison de l'application

Le thread producteur s'arrête lorsque l'utilisateur tape 0. Les threads consommateurs doivent s'arrêter lorsqu'ils ont terminé leurs impressions et que l'utilisateur a signifié au thread producteur la terminaison de l'application. Proposez deux versions de la terminaison:

1. la première version doit faire en sorte qu'à la fin de l'application, chaque thread consommateur appelle pthread_exit();
2. la seconde version doit utiliser le fait qu'un thread peut annuler un autre thread.

Pour aller plus loin

Exercice M. et Mme...

• Le client lit, sur sa ligne de commande, le nom de famille de "M. et Mme". Il l'envoie au serveur.
• Le serveur cherche ce nom de famille dans le fichier mEtMme.txt :
• s'il le trouve, il renvoie le nom du fils, de la fille ou bien des enfants
• sinon il renvoie le message "Désolé, je ne le connais pas"
• Le client affiche le message reçu du serveur.

Architecture client/serveur

1. Le client ouvre (au sens mkfifo du terme) un tube nommé dont le nom est fonction de son "pid" (de manière à ne pas interférer avec d'autres clients potentiels).
2. Le client se "connecte" au serveur via un autre tube nommé (défini par le serveur).
3. La requête du client contient non seulement le "M. et Mme" cherché, mais aussi le nom du tube nommé qui a été créé en 1. par le client et sur lequel le client attend la réponse du serveur.

Attention: repartir des corrigés du chapitre client-serveur:

• client-serveur.corrClientServeur.h
• client.corrClientServeur.c
• serveur.corrClientServeur.c

Question 1: création de threads à la volée

Programmer le serveur de sorte que le thread principal crée un thread à chaque fois qu'il reçoit une requête. Le nouveau thread ouvre le fichier "M. et Mme" et traite la requête:

• il cherche le "M. et Mme" dans le fichier ;
• et il répond au client.

Question 2: création au préalable d'un ensemble de threads et utilisation d'une zone tampon circulaire

Programmer le serveur de sorte que le thread principal crée un pool de N threads:

• chaque thread ouvre le fichier et attend une requête du thread distributeur (le thread principal);
• sur réception d'une requête, le thread distributeur fait suivre la requête à un thread en attente;
• le thread traite la requête (voir question précédente); et une fois terminée, attend une autre requête du thread distributeur.