Dialog

[Fr1nchy]

First comment :)

[Fr1nchy]

Salut, il faut qu'on prenne un rdv avec les profs. 14h30 ça va à tout le monde ?

[thaqifabdullah]

Ok pour moi

[Fr1nchy]

Réunion validée cet aprem autour de 16h.

[x5pid]

Ne pas oublier: AddrSpace::SaveState () A faire .

[x5pid]

Résoudre le problème: Registre mutlithread (même valeur) Rajouter dans l'étape 2 : des tests (voir limite put, get , add '\0' ) Regardez pour enlever userthreadExit

[x5pid]

Erreur : ./nachos-userprog -rs 10 -x ./makethreads 2 2 Machine halting!

Ticks: total 726, idle 341, system 270, user 115 Disk I/O: reads 0, writes 0 Console I/O: reads 0, writes 4 Paging: faults 0 Network I/O: packets received 0, sent 0

Cleaning up...

Pour le programme make thread: void printChar(void c) { char s = ((char*)c); PutChar(s);

if(s =='1'){
    UserThreadJoin(t2);
}

PutChar('\n');
UserThreadExit();

}

int main() { char c = '1'; t1 = UserThreadCreate(printChar, &c); char d = '2'; t2 = UserThreadCreate(printChar, &d);

UserThreadJoin(t1);

Halt();

}

[Fr1nchy]

Erreur détectée dans SynchConsole::SynchGetInt(int *n) : si l'utilisateur entre juste "-", la fonction marche mais enregistre "-\0" dans le buffer donc pas un nombre : A CORRIGER !

[KyronNextLevel]

J'ai corrigé quelques petites fautes sur le rapport et j'ai rajouté les prototypes des fonctions thread user dans les spécifications. Il aurait fallu répondre aux questions suivantes :

is there a parent relation between thread or process ?
who is allowed to make a join ?
identifier are, of course, unique during the live-time the the corresponding thread/process. But are they unique in the machine live-time (ie no reuse of ID)? For thread ID, are they unique in the system or in the process? If they are reused, at which time a programmer can expect to see again a ID already used?

Il aurait fallu aussi présenter les tests pour les threads mais comme je n'ai pas suivi cette partie je ne peux le faire sans y passer beaucoup de temps. J'ai envoyé le rapport sur moodle.

[Hosseim]

La salle habituelle est prise ce matin, je suis en 212 en ce moment si vous voulez me rejoindre ou bien je vous rejoins si vous êtes dans une autre salle

[x5pid]

Dans le rapport les modifications à faire :

• mise en page: (à faire)

• Introduction: ("un grand logiciel" à modifier ) (plus d'information: diffèrentes parties, sur le plan de la table)

• mettre à jour les tables des matières (Définir des sous parties)

• Fonctionnalités principales: (Définir en fonction des cas limites ) (Définir les optimisations qu'on peut effectuer)

-Spécifications : (Revoir la mise en page) (Définir les cas limites) (mettre les variables: "variable" affichage )

• Test utilisateur: (Tout à revoir) (Auncun affichage de tests : résultat explication Attention en fonction du nombre de page ) (Pour quoi on a choisi les tests ?? qu'est que tu veux prouver ) (Répétition des spécifications) (On ne voit pas l'ensemble des tests effectués ???!!!) (Comment le prof doit exectuer un test "readme ) (Donner des noms de fichier plus explicites )

• Implémentation : (Pourquoi on a choisi dans notre programme c'est cas limites ??) (variable entre "")

• Organisation : (Pourquoi le diagramme de Gantt n'est pas présent ???!!!)

[x5pid]

Au niveau des threads dans start.s regarder le exit comme dans le main

[x5pid]

Refaire le SynchGetInt(int *n) erreur dans le programme Faire des tests

[x5pid]

Exemple: // / Test 2: / // Ecriture d'une chaine de caractères de 5 caractères Puis lecture de la chaine caractères Taille du buffer à 10 Test: Taille données < buffer

azert==azert

// / Test 3: / // Ecriture d'une chaine de caractère de 10 caractères Puis lecture de la chaine caractères Taille du buffer à 10 Test: Taille données = buffer

azertyuiop == azertyuiop

[Fr1nchy]

Dernier commit : changement de la valeur du bid à la création et à la fin du thread (non testé !). => re tester les valeurs de retour en multithreading.

[Fr1nchy]

Réponse de V Danjean à mon dernier mail :

Nous avons quelques incompréhensions concernant le projet au niveau de la mémoire. D'abord il y a beaucoup de variables liées à la mémoire et ce n'est pas évident pour nous de comprendre ce à quoi elles correspondent (taille physique ? virtuelle ?) Voici ce que nous avons compris :

Dans addrspace.h : UserStackSize 1024 taille physique de la pile d'un processus

Oui, pour un processus monothreadé. N'hésitez pas à changer la valeur et/ou changer le code qui utilise cette valeur dans addrspace.cc

Dans machine.h : MemorySize (32*128) = 4096 octets au total quantité totale de mémoire physique de NachOS

Oui. Quand vous aurez threads et processus, vous pourrez augmenter un peu NumPhysPages, ce qui augmentera MemorySize. C'est la seule modification dans machine/* autorisée.

Dans thread.h : StackSize (4 * 1024) // in words taille physique de la pile d'un thread user

Non, c'est la taille de la pile des threads noyau de NachOS (ie des threads qui vous sont déjà fournis. La pile des threads utilisateurs (dans la mémoire MIPS), c'est à vous de la gérer (allocation, ...)

Est-ce correct ? Et avons-nous des informations sur les quantités de mémoire virtuelle des processus/threads ?

C'est vous (surtout dans le sujet 4) qui choisissez ce que vous mettez dans la mémoire virtuelle des processus. Il faut regarder le code de AddrSpace::AddrSpace() dans userprog/addrspace.cc. Vous aurez besoin de modifier ce code dans l'étape 4.

Par ailleurs, pour l'implémentation de ReadAtVirtual au début de l'étape 4, que doit-on passer en paramètre virtualAddr ?

Et bien l'adresse virtuelle à laquelle vous voulez charger les données.

Notamment, si ce paramètre contient l'adresse virtuelle, à quoi servent PageTable et numPages ?

PageTable (et numPages) sont les infos de la pagination à utiliser. Ça dépend comment vous faite votre code, mais il est possible que vous ayez besoin de charger des données dans un autre processus que celui courant (typiquement dans le processus fils en cours de création). Dans ce cas, il faut bien indiquer à ReadAtVirtual le mapping mémoire à utiliser.

Cordialement, Vincent Danjean

[x5pid]

userjoin(): erreur si deux threads attendent le même thread car qu'une incrementation sem->V();

[x5pid]

Le thread principal a comme tid par défaut -1, possibilité de créer une erreur(join et pile). Erreur au niveau thread : OK: void printchar(void c){ char s = ((char)c); Putchar(s); .... } Erreur on a perdu la valeur de s: void printchar(void c){ char s = ((char)c); PutChar('a'); PutIng(44); Putchar(s); .... } Augmentation de l'espace entre les piles des deux programmes liès un problème de pile aucun effet. Problème de changement de context (réécriture des registres mais c'est pas lié à notre programme ). Bizzare

[Fr1nchy]

userjoin(): erreur si deux threads attendent le même thread car qu'une incrementation sem->V();

On a dit qu'on ne gérerait pas ce cas. Il n'est pas géré non plus dans Unix.

[thaqifabdullah]

pourquoi j'ai toujours ce genre d'erreur quand j'éxecute le programe ./nachos-filesys

./nachos-filesys -l

Assertion failed: line 121, file "../machine/disk.cc" Abandon (core dumped)

[x5pid]

gdb --args ./nachos-userprog -d ma -x ./testForkExec | less stty sane

[x5pid]

121 addressage.cc bitmap = new BitMap(nbThreadsMax) modifier

[Fr1nchy]

https://pastebin.com/q6Auz6xd

[x5pid]

le 1er : test -Montrer récupérer l'information du thread et le retenir -d’écrire des informations et de vérifier si dans la pile on écrase pas d'autres informations

[x5pid]

test : faire getchar puis putchar puis geting puis puting

[Fr1nchy]

Rappels et infos sur les OS qui peuvent servir : https://codeburst.io/how-operating-systems-work-10-concepts-you-should-know-as-a-developer-8d63bb38331f

[Fr1nchy]

Erreur sur les processus : ./nachos-userprog -x ./makethreads Fonctionne avec le PutChar fait dans la fonction. Ne termine pas lorsque la fonction ne fait rien.

[KyronNextLevel]

RETOUR RAPPORT !

Bonjour,

Merci de votre envoi, voici mes impressions:

• Introduction : ne perdez pas de place à nous dire des choses que nous savons déjà. Ici c'est l'endroit où vous mettez en avant, da manière brève, ce que vous avez réussi à mettre en place dans NachOS.

• Fonctionnalités principales - du coup ce sera ici

• Spécifications : ne pas parler en termes d'étapes mais en termes d'aspects système

  • Écrit le caractère ch dans la sortie définie précédemment (à l’initialisation de SynchConsole()) : ceci n'est pas très informatif pour l'uilisateur qui ne doit pas avoir de connaissance de l'implémentation du système. Est-ce que putc de Linux fait allusion à une qqconque structure noyau?
  • Récupère et renvoie un caractère à partir de l’entrée définie précédemment. : même remarque, il s'agit des E/S standard
  • Récupère n caractères de la chaîne de caractères via l’entrée —> définie précédemment et à corriger comme dans les autres —> les stocke dans la chaîne s stockée - stockée? en paramètre ->
  • void SynchPutString(const char s[]) - Le comportement est indéfini dans le cas où s ne contient pas de ‘\0’. - c'est bizarre, non?
  • UserThreadCreate : vous avez un A VERIFIER et vos mélangez des aspects d'implém
    • avant les appels système de manip de threads il faut expliquer à l'utilisateur quel est le modèle avec lequel il programme par exemple si le premier thread (main) est important et fait des choses différentes
  • static void StartUserThread(int f) n'est pas un appel système

• Tests

  • pour tester le multithreading je vous conseille de faire un "vrai" pg multithreadé où les différents threads se coordonnent (synchronisent) pour faire des choses, partagent des données. L'idéal ce serait d'exporter les sémaphores au niveau utilisateur et d'implémenter un pb de synchro comme ceux qu'on a vu en CSE pendant el semestre.

• Implémentation : pa par étape et choisir les choses importantes / intéressantes et non ce qui est donné dans le sujet et où vous n'avez pas vraiment des choix à faire

Bien cordialement

[Fr1nchy]

Notes pour le rapport :

• dans le système de fichiers :
  • Les dossiers parcourus ne sont pas considérés comme des fichiers ouverts.
  • La limite des 10 fichiers concernera le nombre de fichiers ouverts simultanément par l'utilisateur pour chaque thread (multithreading sur filesys non géré pour l'instant).
  • La destruction des fichiers est implicite dans Nachos et s'effectue à la destruction de l'objet OpenFile.
• pour les specs, prendre le descriptif de l'étape 5 comme exemple.

A faire : Ajouter une sécurité sur le nombre de threads max à la demande de création d'un nouveau thread user.

[x5pid]

215

[thaqifabdullah]

J’ai un entretien ce matin au labo à la gare

[x5pid]

201

[Fr1nchy]

Je fait de la paperasse de stage. Je serai là vers 10h.

[KyronNextLevel]

Comment faut-il appeler la fonction GetString() afin de récupérer une chaîne de caractères dans la console ? Actuellement elle ne laisse pas écrire dans la console et le buffer reste vide... Le bug est provoqué uniquement quand GetChar() et GetString() sont appelés à la suite.

[x5pid]

213

[Fr1nchy]

Pour demain matin !

Peio : débugguer tests 4 + mettre dans rapport + mettre specs 2 et implem 2 dans rapport Hosseim : finir specs 5 + mettre implem 5 dans rapport Flo : finir specs + débugguer tests 4 + mettre implem 3 + parties implem 5 que j'ai faites Cedric : tests 6 + mettre dans rapport + mettre implem 3 + compléter phrase sur le réseau dans l'intro. Thaqif : mettre tests 2 et 3 dans rapport

Pour les trucs à "mettre dans le rapport", il s'agit juste du contenu ! Si le latex vous emmerde (parce qu'il faut un éditeur latex), mettez le contenu dans un fichier texte et je l'ajouterai au latex demain.

[x5pid]

211

[KyronNextLevel]

216, pas 211

[thaqifabdullah]

Test E/S; testEtape2.c : Un programme qui fait l'interaction avec l'utilisateur via les E/S standard. Ce programme utilise les appels système GetChar, PutChar, GetString, PutString, GetInt et PutInt. Si on passe une châine de caractère à GetChar(), il ne prend que le premièr caractère du châine et ensuite l'appel GetString affichera le reste des caractères ce qui montre un mauvais comportement. L'utilisateur doit entrer strictement un caractère à GetChar.

Test Threads Utilisateurs; makethreads.c : Programme donné dans le sujet de l’étape 3. Crée 6 threads et leur demande d’afficher chacun un caractère qui sera aussi affiché par le thread principal. Le thread principal affiche un caractère puis attend chaque thread alternativement. Ce test permet de vérifier que les threads se lancent, exécutent une fonction et sont bien attendues par le main en cas de join().

test3threads.c : Création de deux threads affichant l’entier 44, le caractère ‘’ puis 5 ou 10 en fonction du thread 1 ou 2. Ce test permet de vérifier que l’on peut récupérer les informations concernant le thread et le non dépassement de pile.

test3_1threads.c : Création de threads qui vont afficher chacun une valeur différente t[i] d’un tableau t suivie d’un retour à la ligne. Le thread principal fait ensuite un join() pour tous les threads créés. Ce test simple permet de vérifier la validité du fonctionnement de UserThreadCreate(), sa valeur de retour, et UserThreadJoin().

testMultithreading.c : Creation beaucoup de threads pour savoir combien de threads sont supportés. Notre système d'operation peut supporter au plus 16 threads utilisateurs. Le système se bloque si on execute plus de 16 threads en raison de dépassement de capacité mémoire.

testSemThreads.c : Programme qui crée un producteur et 3 consommateurs. Le producteur initialise le buffer avec une suite de caractèr ASCII puis signaler les consommateurs qui attendent le buffer que soit plein. Le consommateur doit remplacer le caratère lu du buffer avec un caractère 'x' pour indiquer aux autres consommateurs que le caratère a été lu. Ce test permet de tester la bonne utilisation d'un semaphore au niveau utilisateurs.

[Hosseim]

Il faut mettre le rapport en .pdf sur le Moodle (là où on a notre note, cf. le mail de V. Danjean), n'importe qui peut le faire mais je voulais avoir la confirmation que rapport/rapport.pdf sur le Git est la version la plus à jour ?