= QUESTIONS sur le TP9 / 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 ? ==

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'' ? == 

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 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'' sont garanties être effectivement exécutée AVANT l'exécution de la première instruction de lecture/écriture placé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 coeur MIPS32 utilisé dans l'UE Multi, ce coeur exécute les instructions du code binaire en respectant strictement l'ordre des instructions (au contraire d'autres implémentations qui autorisent une exécution dans le désordre.

Pour ce qui concerne le contrôleur de cache L1 utilisé dans l'UE Multi, il 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 donc 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.