Changes between Version 7 and Version 8 of MultiCourseTP9_QR

Timestamp:

Jun 9, 2020, 10:31:00 PM (5 years ago)

Author:

alain

Comment:

--

MultiCourseTP9_QR

@@ -1 +1 @@
 = QUESTIONS sur le TP9 / Synchronisation dans les applications parallèles coopératives =
 
-== Q1) Pourquoi le mécanisme de synchronisation par 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, autres que les instruction ''lw'' et sw'' ? ==
 
-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). 
+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. Le tampon ne peut donc être que dans deux états : PLEIN ou VIDE, et ce tampon 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.
@@ -9 +9 @@
 == Q2) Pourquoi la fonction atomic_increment(), utilisée en particulier par la fonction de prise du verrou à ticket, a-t-elle absolument besoin d'instructions assembleur spéciales qui garantissent une ''lecture_puis_écriture_atomique_à_la_même_adresse'' ? == 
 
-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. 
+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 : ''lw'', (ii) incrémenter cette adresse : ''add'', (iii) écrire la valeur à l'adresse X : ''sw''.
+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: lw_A, puis lw_B, puis sw_A, puis sw_B. Cette  séquence donnera la même valeur de ticket aux 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 . 
+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 à l'adresse X. C'est cette garantie qu'apporte les deux instructions ''ll'' et ''sc'' 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'' ? ==