10. TP2 : exigences, sources et livrables

10. TP2 : exigences, sources et livrables

10.1 Cadre et état réel du travail

Utilisation des threads, 9 % du cours, équipe de 1 à 4. IA : non autorisée selon la fiche officielle. L’énoncé recommande 2 à 4 mais permet l’individuel. Cette section synthétise les contrats et les fichiers; elle n’est ni une réalisation du TP ni un jeu de résultats expérimentaux. Aucun programme, mode privilégié ou VM n’a été exécuté ici.

La fiche et le courriel du 13 octobre 14 h 38 fixent le 10 novembre 2026 à 23 h 55. Le PDF dit avant 23 h 59 : retenir 23 h 55, conforme à la plateforme et plus prudent. Tous les fichiers remis doivent compiler dans la VM Linux du cours; une non-compilation est fortement pénalisée. Le gabarit Word est obligatoire et doit servir à produire rapport.pdf. Le dépôt devient disponible après création de l’équipe; l’agent n’en a créé aucune.

Le module contient sept ressources : énoncé 8 pages, gabarit et cinq sources threads.c, file-main.cxx, file_abstraite.h, file.h, file.cxx. Les deux dernières sont les seules modifiables pour la partie file. Le vrai nom de l’interface emploie _, bien que le PDF l’écrive parfois avec un tiret. La VM est référencée comme environnement, sans téléchargement supplémentaire ou authentification conservée.

10.2 Section 0 : produit matriciel, 10 points bonus

Le travail est noté sur 100, avec 10 points bonus pour cette section. Multiplier G de dimension N×M par H de dimension M×P pour former R de dimension N×P. Créer N×P threads, un par cellule R[i, j]. Chaque calcul est un produit scalaire de longueur M entre la ligne i de G et la colonne j de H; les cellules résultantes sont distinctes.

L’exemple de l’énoncé est 3 ×4 multiplié par 4 ×2 : six cellules a à f, donc six threads. Le squelette threads.c fixe N8/M10/P5, donc 40 threads : ne pas substituer les dimensions de l’exemple sans raison. ParametresThread contient indice, longueur, deux vecteurs de taille M et adresse pResultat. Fournir une structure distincte par thread, avec un contenu valide tant que le travailleur l’utilise; passer son adresse à pthread_create.

La fonction ProduitScalaire fournie convertit seulement l’argument puis quitte. Le travail demandé est calculer le résultat, écrire à l’adresse reçue et quitter par pthread_exit(NULL). Main doit créer les calculs et les attendre avant l’affichage final. Le sujet fournit la liaison -lpthread.

La source initialise G et H selon la règle numérique i+j*0.01; AfficherMatrice parcourt un tableau contigu par rangées avec l’indice i*ncolonnes+j. R est sans calcul/initialisation effective avant l’affichage du squelette. Le message prédéfini « tous les threads ont terminé » n’est pas une preuve de création ou de join : ces étapes restent à compléter. Aucun résultat de matrice n’est déclaré obtenu.

10.3 Section 1 : priorités 20 points, FIFO/RR10 points

Étape 1.1 — nice. Écrire priority.c avec cinq threads POSIX et une boucle infinie de travail. À cette étape, organiser seulement main et work. Chaque thread obtient son TID Linux avec syscall(SYS_gettid) puis appelle setpriority(PRIO_PROCESS, threadID, priority). Relever la valeur retournée et errno pour chaque thread. Nice −20 à 19 est distinct de l’indice interne et de la priorité temps réel.

Le sujet propose errno, pthread, stdio, stdlib, sys/resource, sys/syscall, sys/time, sys/types, sys/wait et unistd comme headers. Les valeurs attendues ne peuvent pas remplacer les sorties de la VM demandée; ne pas attribuer des retours ou erreurs non mesurés à ces cas.

Étape 1.2 — politiques. Configurer la VM avec un seul cœur. Utiliser sched_setscheduler, <sched.h>, sched_param et son champ sched_priority; obtenir les bornes par sched_get_priority_min/max; utiliser errno et éventuellement strerror pour expliquer un échec. pid=0 vise le thread appelant sous Linux, nuance du mot « processus » employé par l’énoncé. La documentation liée redirige depuis SysTutorials; son contrat est recoupé avec Linux man-pages.

Dans l’interface documentée, les politiques ordinaires emploient sched_priority 0; FIFO/RR emploient les bornes 1–99. Succès 0, échec−1 avec errno : EINVAL paramètres/politique invalides, EPERM privilèges insuffisants, ESRCH cible introuvable. Ces niveaux n’ont pas le sens des indices internes 100–139 ni de nice. FIFO et RR peuvent partager le même niveau; leur nom seul ne fixe pas une supériorité entre classes de ce test.

Le sujet fait d’abord écrire scheduler_to_fifo() qui annonce succès/échec, puis généraliser en change_scheduler(int scheduler). Tester FIFO avec une priorité identique pour les cinq threads, puis RR avec une priorité identique, et expliquer leurs sorties. Des droits administrateur peuvent être nécessaires; aucun sudo ou appel n’est exécuté par cette synthèse.

Le fichier final doit contenir exactement main, work, change_scheduler. La fonction intermédiaire scheduler_to_fifo ne devient pas une quatrième fonction finale. Les contraintes successives « deux fonctions » puis « trois fonctions » concernent les étapes, pas deux exigences finales incompatibles. Remplir les sorties FIFO/RR du rapport à partir des expériences, sans les prédire depuis un dessin idéal.

10.4 Section 2 : file bornée, 66 points

Quatre fichiers C++11 composent le montage; modifier seulement file.h et file.cxx. Capacité 10, signatures publiques conservées; les membres privés peuvent être adaptés.

• Insere(const ItemFile&) doit bloquer lorsque la file est pleine, puis insérer sans perdre d’élément.
• Retire(ItemFile&) doit bloquer lorsque la file est vide mais qu’il peut encore arriver des éléments; un retrait réussi retourne true.
• Termine() annonce qu’aucune insertion future n’arrivera. L’appelant garantit l’appel après sa dernière insertion. Réveiller les consommateurs concernés, le sujet signalant l’intérêt d’un broadcast.
• Après cette annonce, les éléments déjà présents restent retirables. Retire retourne false seulement si terminaison annoncée ET file vide. « Vide maintenant » n’est pas « plus aucun futur élément ».

Les attentes logiques appellent une synchronisation bloquante, pas une boucle active. La capacité doit rester 10 et les consommateurs doivent pouvoir sortir lorsque tout est fini, y compris ceux qui attendaient déjà.

Les sources répartissent les rôles :

Le pilote par défaut utilise 3 producteurs, 3 consommateurs, 50 items. Un producteur prépare un générateur et un item, prend le mutex d’attribution, revérifie le compteur, attribue numéro/valeur, appelle Insere et imprime son message dans cette zone. Les délais fondés sur sinus/valeur font varier les entrelacements. Le consommateur boucle sur Retire, imprime après le retrait réussi puis attend selon un cosinus/valeur. Les stringstreams visent à limiter les mélanges de caractères, sans garantie absolue annoncée.

Ordre des messages ≠ ordre de retrait. Un consommateur peut retirer n, être suspendu avant son affichage, tandis qu’un autre retire et imprime n+1. Des lignes console inversées ne démontrent donc pas seules une violation FIFO. Vérifier l’événement partagé et les exigences d’intégrité, d’ordre et de terminaison du sujet; ne pas masquer un échec réel derrière cette réserve.

Main crée producteurs puis consommateurs, joint les producteurs, appelle ma_file.Termine, puis joint les consommateurs. Cette place de Termine établit l’absence d’insertion future. Les erreurs de création déclenchent une exception.

Limites de l’inspection statique du pilote : aucun appel explicite d’initialisation du mutex global d’attribution dans le texte fourni, test externe du compteur hors mutex, retours finaux des fonctions travailleurs absents. Leur effet expérimental n’est pas établi ici. Ne pas présenter ces observations comme un test échoué ni modifier les fichiers interdits pour les corriger; signaler une difficulté à l’équipe enseignante si elle apparaît pendant le travail.

10.5 Tests, rapport et cinq fichiers de remise

Compilation prescrite :

g++ -o file file.cxx file-main.cxx -lpthread -std=c++11

Si g++ manque, le PDF propose sudo apt install g++ dans la VM; aucune installation n’a été faite ici. La longueur indicative d’environ 50 lignes de la solution enseignante n’impose pas une limite de code.

Exécuter les quatre cas, vérifier terminaison et intégrité, indiquer honnêtement ceux qui ne fonctionnent pas; le sujet prévoit des points partiels. Le rapport contient la sortie du premier cas, pas quatre sorties inventées. Les autres cas impliquent l’ajustement des constantes dans l’environnement de test, pas une permission de remettre un pilote modifié.

Le gabarit possède trois rubriques et neuf tableaux : identité/IDUL et cinq sorties nice avec explication f; sorties FIFO/RR avec interprétation; tableau de réussite des quatre cas de file et sortie du premier. Les cases sont vides avant les expériences. Le bonus matrice n’y a pas de rubrique distincte observée; ne pas lui inventer une rubrique officielle. La pagination Word n’est pas validée par la lecture de son contenu.

La remise numérique vaut 4 points et demande uniquement cinq fichiers : rapport.pdf, threads.c, priority.c, file.cxx, file.h. Ni gabarit Word, ni interface, ni pilote ou autre fichier n’est demandé. Le texte lu ne fixe pas une extension d’archive particulière. Le fichier threads.c est listé malgré le caractère bonus de la section 0 : si l’on renonce au bonus, clarifier cette articulation plutôt que supposer sa suppression des livrables. Rien n’est déposé ou réalisé par ce maître.