Changes between Version 7 and Version 8 of MultiCourseTP8_QR
- Timestamp:
- Jun 9, 2020, 7:33:28 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MultiCourseTP8_QR
v7 v8 1 1 = QUESTIONS sur le TP8 / Contrôleur de disque et partage des périphériques = 2 2 3 == Q1) La prise du verrou protégean l'accès exclusif au contrôleur de disque est réalisée par les appels système ioc_read() et ico_write(), et utilise les instructions spéciales ''ll(X)'' et ''sc(X)''. Quels événements peuvent casser la ''prise de réservation'' sur l'adresse X réalisée par l'instruction ''ll(X)'' ? == 4 5 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 pas les instructions ''sw(X)'' et ''sc(X)''. 6 Le plus souvent c'est le premier concurrent qui exécute une instruction ''sc(X)'' qui gagne le concours et casse la réservation. 7 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() ? == 3 == Q1) 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() ? == 9 4 10 5 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. … … 14 9 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. 15 10 16 == Q 3) 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 ? ==11 == Q2) 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 ? == 17 12 18 13 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. … … 20 15 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. 21 16 22 == Q 4) Pourquoi ne trouve-t-on pas dans LINUX l'appel système ioc_completed() du GIET ? ==17 == Q3) Pourquoi ne trouve-t-on pas dans LINUX l'appel système ioc_completed() du GIET ? == 23 18 24 19 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. … … 26 21 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. 27 22 28 == Q 5) 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 ? ==23 == Q4) 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 ? == 29 24 30 25 Je pense que c'est tout simplement une erreur de programmation dans le GIET. Cela n'a pas de conséquences négatives dans les cas des utilisations du composant IOC vues en TP, mais c'est clairement un bug inacceptable pour un véritable OS : supposons qu'une application commette une erreur d'adressage après avoir exécuté l'appels système ioc_read() (non bloquant) mais avant d'exécuter l'appel système ioc_completed(). Cette erreur d'adressage déclenche une exception fatale, et l'application va être tuée par l'OS. L'appel système ioc_completed() ne sera donc pas exécuté, et le verrou ne sera pas relâché, ce qui rend le contrôleur de disque inutilisable pour toutes les autres applications, ce qui est un peu ennuyeux. C'est donc en effet l'ISR qui doit relâcher le verrou quand le transfert est terminé. 31 26 32 == Q 6) Pourquoi ne pas définir des primitives permettant lire et d'écrire sur le disque octet par octet plutôt que bloc par bloc ? ==27 == Q5) Pourquoi ne pas définir des primitives permettant lire et d'écrire sur le disque octet par octet plutôt que bloc par bloc ? == 33 28 34 29 Lorsqu'un programme ne modifie que quelques octets dans un block de 512 octets, il semble déjà peu efficace de copier le bloc complet du disque vers la mémoire, puis de modifier quelques octets en mémoire, avant de recopier ce block modifié sur le disque. Pourtant la réalité est encore plus compliquée... … … 38 33 * tous les mouvements de données entre le cache du fichier et le disque sont effectués par l'OS et se font avec une granularité ''page'', soit cas de MISS sur le cache de fichier, sot lors de la fermeture du fichier. 39 34 40 == Q 7) Pourquoi, à la fin d'un transfert de fichier vers une clé USB, est-il nécessaire de ''cliquer'' sur "retirez le périphérique en toute sécurité" ? ==35 == Q6) Pourquoi, à la fin d'un transfert de fichier vers une clé USB, est-il nécessaire de ''cliquer'' sur "retirez le périphérique en toute sécurité" ? == 41 36 42 37 Une clé USB est un périphérique de stockage de blocs, qui se comporte donc comme comme un disque magnétique. Les temps d'accès sont mille fois plus plus courts que pour un disque, mais restent mille fois plus longs qu'un accès à la mémoire.
