Changes between Version 34 and Version 35 of AS6-TME-B5

Timestamp:

Feb 22, 2022, 10:57:50 AM (3 years ago)

Author:

franck

Comment:

--

AS6-TME-B5

@@ -358 +358 @@
 '''
 }}}
-1. Dans le deuxième TME2, vous avez dû modifier le code `syscall_handler` (gestionnaire de syscalls) pour le rendre interruptible. En effet, lorsque l'application demande un service au noyau, mais que le noyau ne peut pas le rendre immédiatement (comme la lecture d'une touche du clavier), si vous restez bloqué dans l'appel système en attendant la donnée et que les interruptions sont masquées, alors le noyau ne peut pas gérer les IRQ (pour le TME 2, il ne pouvait pas gérer l'IRQ du timer pour gérer le dépassement du temps de jeu). Pour rendre l'appel système interruptible, vous aviez dû mettre 0x401 dans le registre `c0_sr` dans le gestionnaire de syscall, avant d'appeler la fonction de service. Nous allons changer cette politique et considéré que les appels système ne sont plus interruptible
-{{{#!protected ------------------------------------------------------------------
-'''
- * w
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
+1. Dans le deuxième TME2, vous avez dû modifier le code `syscall_handler` (gestionnaire de syscalls) pour le rendre interruptible. En effet, lorsque l'application demande un service au noyau, mais que le noyau ne peut pas le rendre immédiatement (comme la lecture d'une touche du clavier), si vous restez bloqué dans l'appel système en attendant la donnée et que les interruptions sont masquées, alors le noyau ne peut pas gérer les IRQ (pour le TME 2, il ne pouvait pas gérer l'IRQ du timer pour gérer le dépassement du temps de jeu). Pour rendre l'appel système interruptible, vous aviez dû mettre 0x401 dans le registre `c0_sr` dans le gestionnaire de syscall, avant d'appeler la fonction de service. Nous allons changer cette politique et considérer que les appels système ne sont plus interruptibles.\\Quelle(s) conséquence(s) voyez-vous pour les appels système ?
+{{{#!protected ------------------------------------------------------------------
+'''
+ * Si les appels système ne sont plus interruptibles, ils ne doivent plus être bloquants !
+'''
+}}}
+1. Que doit-faire le noyau si un thread lui demande une ressource qu'il n'a pas ? Il ne peut pas attendre la ressource, alors il a deux possibilités, les voyez-vous ? Mettez-vous à sa place si vous devez gérer des ressources, par exemple des places dans un restaurant, que vous avez des clients qui se présentent et que toutes les places sont occupées. Que faites-vous ?
+{{{#!protected ------------------------------------------------------------------
+'''
+ * Deux possibilités :
+   1. Soit le noyau abandonne le service et rend une erreur au thread pour l'informer que le service ne peut pas être rendu, et donc que le thread doit re-tenter sa chance plus tard ou faire autre chose. Pour l'analogie, vous dites à votre client de partir et de, s'il veut, revenir plus tard ou pas.
+   2. Soit le noyau demande un changement de thread avec `thread_yield()` pour faire quelque-chose d'utile pour un autre thread. Pour l'analogie, vous dite à votre client d'attendre et vous allez faire autre chose. Le client attend et tente de rentrer dès qu'un autre client sort du restaurant. Notez que dans cette analogie, il n'y a pas de file d'attente, le dernier client arrivé sera peut-être le premier servi.
+ * Dans la version actuelle du code, le thread qui attend la ressource reste dans l'état READY et donc il sera élu par l'ordonnanceur quand son tour viendra pour tester à nouveau la ressource et la prendre si elle est disponible, sinon il subit à nouveau un `thread_yield()`.
+ * Ce comportement sera modifié en introduisant un état `WAIT` pour les threads afin de l'ordonnanceur ne donne pas le processeur à un thread dont la ressource attendue n'est pas disponible.
 '''
 }}}