Changes between Version 2 and Version 3 of MultiCourseTP8_QR

Timestamp:

Jun 9, 2020, 6:52:35 PM (5 years ago)

Author:

alain

Comment:

--

MultiCourseTP8_QR

@@ -8 +8 @@
 == Q2) Que se passe-t-il si deux tâches qui s'exécutent en pseudo-parallélisme sur le même coeur (par multiplexage temporel) font toutes les deux un appel système ioc_read() ? ==
 
-La concurrence d'accès lié au pseudo-parallélisme pose les mêmes problèmes que la situation où deux tâches A et B s'exécutent sur deux coeurs différents en vrai parallélisme. 
+La concurrence d'accès lié au pseudo-parallélisme pose les mêmes problèmes que la situation où deux tâches A et B s'exécutent en vrai parallélisme, sur deux coeurs différents. 
 
-Chacune des tâches A et B a défini son propre tampon destination dans son propre espace d'adressage.
-La seule ressource partagée est donc le contrôleur IOC qui déplace les données du disque vers la mémoire.
-La première tâche (A) qui réussit à prendre le verrou continue son exécution et peut donc lancer le transfert requis entre le disque et la mémoire. La deuxième tâche (B) est bloquée dans la fonction de prise de verrou. Dans le cas du GIET ce blocage est réalisé par une boucle d'attente active ou la fonction de prise de verrou teste la valeur du verrou jusqu'à obtenir une valeur nulle signalant que le contrôleur IOC est redevenu libre. Heureusement les appels systèmes sont interruptibles, et les autres applications peuvent continuer à s'exécuter dans les tranches de temps qui leur sont allouées. Mais la tâche B utilise toutes ses tranches de temps à faire de la scrutation sur l'adresse du verrou, ce qui est clairement du gâchis. les systèmes d'exploitation généralistes ont une politique plus intelligente consistant à mettre en sommeil la tâche B jusqu'à libération du verrou, ce qui évite de consommer inutilement des tranche de temps. 
+Chacune des tâches A et B a défini son propre tampon mémoire destination dans son propre espace d'adressage.
+La seule ressource partagée est donc le contrôleur IOC qui déplace les données du disque vers le tampon mémoire.
+La première tâche (A) qui réussit à prendre le verrou continue son exécution et peut donc lancer le transfert requis entre le disque et la mémoire. La deuxième tâche (B) est bloquée dans la fonction de prise de verrou. Dans le cas du GIET ce blocage est réalisé par une boucle d'attente active ou la fonction de prise de verrou teste la valeur du verrou, jusqu'à obtenir une valeur nulle signalant que le contrôleur IOC est redevenu libre. Heureusement les appels systèmes sont interruptibles, et les autres applications peuvent continuer à s'exécuter dans les tranches de temps qui leur sont allouées. Mais la tâche B utilise toutes ses tranches de temps à faire de la scrutation sur l'adresse du verrou, ce qui est clairement du gâchis. les systèmes d'exploitation généralistes ont une politique plus intelligente consistant à mettre en sommeil la (ou les) tâche(s) bloquée(s) jusqu'à libération du verrou, ce qui évite de consommer inutilement des tranche de temps. 
 
 == Q3) Pourquoi le verrou protégeant l'accès exclusif au contrôleur IOC est-t-il pris par les appels système ioc_read() et ioc_write() plutôt que par l'application elle-même ? ==