Changes between Version 77 and Version 78 of AS6-TME-B5


Ignore:
Timestamp:
Mar 17, 2024, 6:39:25 PM (6 months ago)
Author:
franck
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AS6-TME-B5

    v77 v78  
    329329{{{#!protected ------------------------------------------------------------------
    330330'''
    331  * Soit c'est lui qui demande par l'appel explicite à `thread_yield()`, soit c'est une interruption d'horloge, soit c'est `thread_exit()`
     331 * Soit c'est lui qui demande par l'appel explicite à `thread_yield()`, soit c'est une interruption d'horloge dans `isr_timer`, soit c'est `thread_exit()`
    332332'''
    333333}}}
     
    342342'''
    343343}}}
    344 1. Dans le cours, nous suivons l'exécution du code au démarrage (vers le slide 37), nous pouvons voir que la fonction `kinit()` fait 3 choses importantes : (1) initialiser à `0` la section `BSS` (contenant les variables globales non explicitement initialisées dans le programme), (2) demander à l'architecture de s'initialiser et (3) lancer la première (et ici seule) application. Où sont définis les symboles `__bss_origin`, `__bss_end`, `__main_thread`, `_start` et quel est leur type ?
     3441. Dans le cours, nous suivons l'exécution du code au démarrage (vers le slide 37), nous pouvons voir que la fonction `kinit()` fait 3 choses importantes : (1) initialiser à `0` la section `BSS` (contenant les variables globales non explicitement initialisées dans le programme), (2) demander à l'architecture de s'initialiser (avec la fonction `arch_init()` donc le code est dans la `harch.c` parce que c'est du code spécifique à l'architecture) et (3) lancer la première (et ici seule) application. Où sont définis les symboles `__bss_origin`, `__bss_end`, `__main_thread`, `_start` et quel est leur type ?
    345345{{{#!c
    346346void kinit (void)
     
    352352
    353353// 2
    354     arch_init(20000);                                         // init architecture ; arg=tick
     354    arch_init(20000);                                         // init architecture ; arg = valeur du tick
    355355
    356356// 3
     
    407407'''
    408408}}}
    409 1. Que doit-faire le noyau si un thread A lui demande une ressource que le noyau n'a pas ?\\Le thread A ne doit pas attendre activement la ressource par scrutation parce que c'est du gâchis de temps CPU, alors le noyau a deux possibilités, les voyez-vous ?\\Mettez-vous à la place du noyau 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 ?
    410 {{{#!protected ------------------------------------------------------------------
    411 '''
    412  * Deux possibilités :
    413    1. Soit le noyau informe le thread A que le service ne peut être rendu en retournant un code d'erreur pour l'informer  et donc que le thread A doit retenter sa chance plus tard ou faire autre chose. Pour l'analogie, vous dites à votre client de partir et de revenir plus tard ou pas.
    414    2. Soit le noyau demande un changement de thread avec `thread_yield()` pour le thread A qui demande la ressource, ainsi le noyau peux faire quelque chose d'utile pour un autre thread. Le thread A reste dans la dans le noya Pour l'analogie, vous dites à votre client de se mettre dans une file d'attente 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.
    415  * 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()`.
    416  * 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.
     4091. Dans la version actuelle du noyau, les threads ne peuvent pas être mis en attente, il n'y a pas d'état `WAIT`. Les threads sont soit `RUNNING`, soit `READY`, soit `DEAD`. Si un thread A fait un syscall pour demander une ressource que le noyau n'a pas (un caractère du clavier par exemple). Que peut-on faire ?
     410{{{#!protected ------------------------------------------------------------------
     411'''
     412 * Il faut faire une attente active en redemandant périodiquement si la ressource est disponible.
     413 * Il y a deux possibilités :
     414   1. Soit le noyau informe le thread A que la ressource n'est pas disponible en retournant un code d'erreur et donc il informe le thread A qu'il doit retenter sa chance. Le thread A va ainsi consommer tous ses quanta de temps jusqu'à ce que la ressource soit disponible. On peut faire cette attente active en restant dans le syscall ou pas.
     415   2. Soit le thread A, voyant que la ressource n'est pas disponible, demande un changement de thread avec `thread_yield()`. Ainsi, le noyau peux élire un autre thread et faire quelque chose d'utile. Le thread A reste `READY` et il reprend périodiquement le processeur pour retenter sa chance. C'est aussi une attente active, mais meilleure parce que les autres threads sont moins pénalisés. En effet, il n'y a pas la perte de quantum de temps par le thread A.
     416 * Dans les deux cas, c'est bien une attente active puisque le thread A teste lui-même si la ressource est disponible jusqu'à réussir.
     417 * Ce comportement sera modifié en introduisant un état `WAIT` pour que les threads en attente ne soient plus éligibles. C'est la libération de la la ressource qui remettra le thread en attente dans l'état `READY.
    417418'''
    418419}}}