Changes between Version 1 and Version 2 of MultiCourseTP9_QR

Timestamp:

Jun 9, 2020, 8:38:30 PM (5 years ago)

Author:

alain

Comment:

--

MultiCourseTP9_QR

@@ -1 +1 @@
 = QUESTIONS sur le TP9 / Applications parallèles coopératives =
 
-== Q1) Pourquoi le mécanisme de synchronisation bar bascule SET/RESET ne nécessite-t-il pas d'instructions assembleur spéciales ? ==
+== Q1) Pourquoi le mécanisme de synchronisation par bascule SET/RESET ne nécessite-t-il pas d'instructions assembleur spéciales ? ==
+
+Dans ce mécanisme, il y a un seul producteur, un seul consommateur, et le tampon de communication ne peut contenir qu'une seule donnée. Ce tampon ne peut être que dans deux états : PLEIN ou VIDE et il a donc toujours un seul propriétaire (le producteur quand il est vide / le consommateur quand il est plein). 
+
+La conséquence est qu'il ne peut pas exister d'accès concurrents en écriture sur ce tampon puisque seul le propriétaire (unique)  du tampon a le droit de modifier l'état du tampon. L'inconvénient de ce mécanisme est qu'il ne peut pas exister de parallélisme entre la tâche productrice et la tâche consommatrice : il y a toujours une des deux tâches qui doit attendre l'autre.
 
 == Q2) Pourquoi la fonction atomic_increment(), utilisée en particulier par la fonction de prise du verrou à ticket, a-t-elle absolument d'instructions assembleur spéciales de ''lecture_puis_écriture_atomique_à_la_même_adresse'' ? == 
 
-== Q3) ==
+Pour incrémenter un compteur stocké à une adresse X (par exemple un distributeur de ticket), il faut exécuter au moins trois instructions assembleur : (i) lire la valeur courante à l'adresse X lord), (ii) incrémenter cette adresse (add), (iii) écrire la valeur à l'adresse X store.
+Cette séquence peut être exécutée de façon concurrente par deux tâches A et B ce qui peut donner la séquence suivante pour les transactions entrelacées sur le bus: load_A, puis load_B, puis store_A, puis store_B. Cette  séquence donnera la même valeur de ticket au deux tâches A et B, ce qui est un résultat faux. 
+
+On a donc absolument besoin d'un mécanisme qui garantit a chaque tache qu'il n'y a pas eu d'autre accès en écriture à l'adresse X entre sa propre lecture, et sa propre écriture. C'est cette garantie qu'apporte les deux instructions ''ll/ss'' du MIPS32 . 
+
+== Q3) Dans le mécanisme ''ll/sc'' l'instruction ll(X) effectue une lecture de la donnée stockée en mémoire à l'adresse X, et en plus, met sous surveillance de l'adresse X (appelée réservation). L'instruction ''sc(X)'' effectue une écriture conditionnelle à l'adresse X, et en plus, retourne un Booléen indiquant si l'écriture est un succès ou un échec. Quels sont les événements qui mettent fin à la surveillance de l'adresse X'' ? ==
+
+Lorsqu'une adresse X a été mise sous surveillance, par une (ou plusieurs) instruction(s) ''ll(X)'', n'importe quelle écriture à l'adresse X casse la réservation, quel que soit l'écrivain. On ne distingue donc pas les instructions ''sw(X)'' et ''sc(X)''.
+Le plus souvent c'est le premier concurrent qui exécute une instruction ''sc(X)'' qui gagne le concours et casse la réservation.
+
+== Q4) == Comment les instructions ''ll/sc'' sont-elles implémentées dans le matériel matériel ? ==
+
+
+== Q5) L'instruction assembleur ''sync'' empêche le re-ordonnancement des instructions par le compilateur ou par le processeur lui-même.
+Plus précisément toutes les instructions de lecture ou d'écriture en mémoire placées avant l'instruction ''sync'' seront effectivement exécutée AVANT l'exécution de la première instruction de lecture/écriture située après l'instruction sync. Comment l'instruction assembleur ''sync'' est-elle implémentée dans le matériel ? ==
+
+Pour ce qui concerne le contrôleur de cache L1 utilisé dans l'UE Multi, le contrôleur de cache garantit que les requêtes de lectures de données qui font MISS ne seront jamais  traitées avant les requêtes d'écritures qui sont en attente dans le tampon d'écritures postées.
+Pour traiter une instruction assembleur ''sync'', l'automate DCACHE_FSM qui traite les requêtes concernant le cache de données peut
+se contenter de geler (c'est à dire faire attendre le coeur) jusqu'à ce que toutes les requêtes d'écriture en attente dans le tampon d'écritures
+postées aient effectivement été traitées et acquittées par l'automate PIBUS_FSM.