Changes between Version 10 and Version 11 of AS6-TME-B5

Timestamp:

Feb 19, 2022, 5:25:11 PM (3 years ago)

Author:

franck

Comment:

--

AS6-TME-B5

@@ -7 +7 @@
 = Rappels de cours
 
+
+
 = A. Questions
+
+
 
 La majorité des réponses aux questions sont dans le cours ou dans le rappel du cours donné au début de cette page, c'est voulu. Les questions suivent à peu près l'ordre du cours, elles sont simples, mais vous avez besoin de comprendre le cours pour y répondre :-)
 Quand une question vous demande si quelque chose est vrai ou faux, ne répondez pas juste "oui" ou "non », mais justifiez vos réponses avec une petite phrase. Le but de ces questions est d'évaluer vos connaissances, donc plus vous êtes précis, mieux c'est.
 
+
+== A.1. Questions générales
+
+
 1. Dites-en une phrase ce qu'est un processus informatique (selon Wikipédia)
 {{{#!protected ------------------------------------------------------------------
@@ -145 +153 @@
 '''
 }}}
-1. Un thread se termine dans deux cas. Dans le premier cas, il fait appel à la fonction `thread_exit()`, explicitement dans la fonction principale du thread ou implicitement au retour de la fonction principale du thread. Cette terminaison volontaire peut être qualifiée de ''suicide''. C'est celle que nous avons vu en cours et que nous pouvons utiliser dans le code actuel. Le second cas de terminaison, non encore disponible, c'est quand un thread demande la terminaison d'un autre par `thread_cancel()`, ce qui provoque chez le thread désigné un `thread_exit()`. Cette terminaison imposée peut être qualifiée de ''meurtre''. Dans les cas du ''suicide'' et du ''meurtre'', pour quelle raison le thread qui va disparaitre, ne peut désallouer sa pile.  
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
-{{{#!protected ------------------------------------------------------------------
-'''
- * 
-'''
-}}}
-1. 
+
+
+== A.2. Questions sur l'implémentation
+
+
+1. Quelles sont les fonctions de l'API utilisateur des threads et les états de threads ? Indiquer les changements d'état provoqué par l'appel des fonctions de cette API.
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. La structure `thread_s` rassemble les propriété du thread, sa pile et le tableau de sauvegarde de son contexte. Cette structure est, dans l'état actuel du code` entièrement dans dans le segment des données globales de l'application. Pouvez-vous justifiez cette situation et en discuter ?
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. Le tableau de sauvegarde du contexte d'un thread est initialisé avec des valeurs qui seront chargées dans les registres du processeur au premier chargement du threads. Tous les registres n'ont pas besoin d'être initialisé avec une valeur. Seuls les registres `$c0_sr` (`$12` du coprocesseur système) , `$sp` (`$29` des GPR) et `$ra` (`$31` des GPR) ont besoins d'avoir une valeur choisie. Pourquoi ?
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. `$c0_sr` est initialisé avec `0x413`, dite pourquoi.
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. La fonction `sched_switch()` appelle d'abord l'électeur de thread qui choisit le thread entrant (qui gagne le processeur), puis `sched_switch()` sauve le contexte du thread sortant (qui perd le processeur) et charge le contexte du thread entrant, enfin `sched_switch()` change l'état du thread entrant à `RUNNING`. `sched_switch()` est appelée par `thread_yield()`. Pouvez expliquer pourquoi avoir créé `sched_switch()` ? Ce n'est pas évident au premier abord, mais il y a une raison.
+{{{#!c
+void sched_switch (void) { //
+  int th_curr = thread_current_idx;                        // n° du thread courant dans thread_tab
+  int th_next = sched_elect ();                            // demande le numéro du prochain thread
+  if (th_next != th_curr) {                                // Si c'est le même thread, ne rien faire !
+    if (thread_save (thread_tab[th_curr]->context)) {      // sauve le ctx du thread sortant et rend 1
+      thread_current_idx = th_next;                        // mise à jour de thread_current_idx
+      thread_load (thread_tab[th_next]->context);          // chargement de contexte & sortie par jr $31
+    }                                                      // donc de thread_save() mais qui rend 0
+  }
+  thread_tab[thread_current_idx]->state= TH_STATE_RUNNING; // the thread choisi est dans l'état
+}
+int thread_yield (void) {
+  thread_tab[thread_current_idx]->state = TH_STATE_READY;  // état futur du thread sortant 
+  sched_switch ();                                         // changement de threads (ou pas)
+  return 0;
+}}}
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. Pour quelle raison, ne sauver que les registres persistants dans le contexte des threads ?
+{{{#!protected ------------------------------------------------------------------
+'''
+ * 
+'''
+}}}
+1. Quand un thread est élu pour la prem
 {{{#!protected ------------------------------------------------------------------
 '''