Changes between Version 3 and Version 4 of MultiCourseTP8_QR

Timestamp:

Jun 9, 2020, 7:05:32 PM (5 years ago)

Author:

alain

Comment:

--

MultiCourseTP8_QR

@@ -16 +16 @@
 == 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 ? ==
 
-La raison la plus importante est que l'OS ne peut pas et ne veut confier à une application particulière la responsabilité de verrouiller et surtout de dé-verrouiller une ressource partagée par un grand nombre d'applications. Par ailleurs l'OS cherche à marquer au code application la complexité liée au partage des périphériques
+La raison la plus importante est que l'OS ne peut pas et ne veut confier à une application particulière la responsabilité de verrouiller et donc de dé-verrouiller une ressource partagée par un grand nombre d'applications. Ce serait en effet prendre le risque que le verrou ne soit pas relâché pr une application mal programmée ou malicieuse. 
+
+Par ailleurs l'OS cherche à masquer au code applicatif la complexité de l'accès au disque, et en particulier les mécanismes de partage. 
 
 == Q4) Pourquoi ne trouve-t-on pas dans LINUX l'appel système ioc_completed() du GIET ? ==
 
-Les appels systèmes visent à fournir aux applications une abstraction la plus simple possible pour faciliter l'écriture du code applicatif. Dans LINUX, il n'existe donc que deux appels système read() et write() qui sont bloquant tous les deux et ne rendent la main que lorsque que le transfert est terminé et que le tampon mémoire peut être utilisé. Le blocage de l'application demandeuse n'est pas pénalisant pour le fonctionnement général de la machine, puisque LINUX utilise une politique de mise en sommeil de l'application demandeuse, plutôt qu'une
-politique de scrutait du verrou qui gâche des cycles CPU.
+Comme indiquéé ci-dessus, les appels systèmes visent à fournir aux applications l'abstraction la plus simple possible pour faciliter l'écriture du code applicatif. Dans LINUX, il n'existe donc que deux appels système read() et write() qui sont bloquant tous les deux et ne rendent la main que lorsque que le transfert est terminé et que le tampon mémoire peut être utilisé. Le blocage de l'application demandeuse n'est pas pénalisant pour le fonctionnement général de la machine, puisque LINUX utilise une politique de mise en sommeil de l'application demandeuse, plutôt qu'une politique de scrutation qui gâche des cycles CPU.
 
-La raison pour laquelle cet appel système a été introduit dans le GIET est que cela permet de souligner qu'une opération d'entrée/sortie est toujours une valse à trois temps : (i) lancement de l'opération par un appel système, (ii) transfert des données, (iii) signalisation de fin de transfert par interruption. Par ailleurs, il permet d'illustrer le mécanisme général de pipe-line logiciel permis par le fait que plusieurs maîtres peuvent travailler en parallèle.
+La raison pour laquelle cet appel système a été introduit dans le GIET est que cela permet de mettre en lumière qu'une opération d'entrée/sortie est toujours une valse à trois temps : (i) lancement de l'opération par un appel système, (ii) transfert des données, (iii) signalisation de fin de transfert par interruption, et que la signalisation de fin de transfert n'est pas moins importante que le démarrage. Par ailleurs, cet appel système est nécessaire pour optimiser le code et construire un pipe-line logiciel qui exploite le fait que plusieurs maîtres travaillent en parallèle.
 
 == Q5) Pourquoi le verrou garantissant l'accès exclusif au périphérique IOC (contrôleur de disque) est-il libéré par l'appel système ioc_completed() plutôt que par l'ISR associée à l'interruption signalant la fin du transfert ? ==