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 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.