Christophe Cérin – Christophe.Cerin at iutv.univ-paris13.fr

Système d'exploitation, DUT informatique Villetaneuse

Polycopiés
Prendre des notes en cours...

Je procède parfois à la relecture de vos notes de cours de «Système» depuis le début d'année afin de les noter. Voici des remarques sur certaines phrases trouvées dans vos copies et qui méritent une ré-écriture car ces phrases sont ambigues (dans le meilleur des cas) ou ne veulent rien dire (dans le pire des cas). Je vous demande de faire l'effort de ré-écriture... c'est à dire de faire un travail de fond.

Chapitre sur les processus, communication locale sous Unix :

  • «on risque d'avoir le coût de communication supérieur au coût d'accès à la mémoire»
  • «L'implémentation 2 nécessite moins de ressource mémoire parce que les instruction sont utilisées moins souvent et en même temps.»
  • «il faut programmer le nombre de messages émis et le nombre de messages reçus» (quelle est la propriété que vous voulez vérifier ?)
  • «plus le processeur est performant, mieux les processus seront ordonnancés»
  • «si le processus père meurt, tout le tube disparaît»
  • «Il faut que le coût pour permettre d'utiliser ces techniques soit inférieur au coût que l'on gagnerait.»
  • «que se passe t-il si deux ressources entrent en conflit pour un espace mémoire identique ?»

Chapitre sur Bash :

  • «la séquence des schémas de choix»
  • «En effet certains terminaux ont été ouverts mais n'ont pas encore été fermés alors que d'autres terminaux ont été ouverts après les premiers mais ont été refermés avant»
  • «Un test devra s'effectuer en amont pour ne sélectionner que l'utilisateur en paramètre ce qui inclue la demande de paramètres»
  • «le Bash est un langage shell»
  • «La commande until est identique à la commande while excepté que le test est négatif»

Chapitre «Appels systeme / Compilation»

  • «popen() : permet de récupérer des fichiers particuliers»

Par ailleurs, il aurait été bon de trouver, pour chaque chapitre de vos notes de cours, les informations suivantes (et en première page) : titre de la leçon, thématique centrale (quel est le problème qui est traité dans la leçon ?), les motivations, les mots clés importants (et définitions), l'organisation de la leçon... puis après tout cela, vous pouvez lister les détails techniques. En bref, comme je l'avais dit dans un précédent courrier, il faut commencer par un «mini sommaire» ! Il faut organiser vos notes de cours et ne pas tout mettre sur le même plan !

Un cours plante le décor, le contexte, donne du vocabulaire, expose une problématique (et certaines techniques de résolution qui seront mises en oeuvre en TD/TP). Un cours fait jouer les savoirs les uns par rapport aux autres autour d'un objet donné qui peut être très concret (exemple : les différents itérateurs de Bash) ou très abstrait (exemple : la prise en compte de l'accès exclusif aux ressources par des solutions logicielles). Encore une fois, c'est donc tout cela qu'il faut faire ressortir dans vos notes de cours afin de vous approprier les notions. De plus vous êtes impardonnables car à chaque début de cours je fais un résumé des épisodes précédents, donc vous avez de la matière pour rédiger vos notes !

Exercices de travaux dirigés et pratiques

À priori les travaux pratiques se préparent à l'avance. Lors de la séance, vous éditez, compilez, exécutez, observez vos résultats, modifiez, compilez, exécutez, améliorez, compilez, exécutez... jusqu'à ce que la solution soit acceptable (par votre enseignant et par vous !). Le programme est le suivant :

Sujets d'examen et corrections

Quelques conseils pour commencer. Pour chaque exercice, pensez toujours à faire une introduction pour exposer les problèmes (où est la «vraie» difficulté dans le problème ?), pour citer, discuter vos approches, faire des hypothèses, justifier vos choix, présenter les variables importantes et leurs rôles. Passez toujours par une phase de construction d'un algorithme avant de vous lancer dans la codification. Un code doit toujours découler d'une représentation abstraite la plus simple possible qui cerne et surmonte les difficultés essentielles du problème... et ceci même lorsque le sujet est un sujet relatif aux Systèmes d'Exploitation.

Au sujet de Bash, notez que ce langage de programmation est avant tout orienté «contrôle d'exécution». Vous avez utilisé des constructions comme for i in `ls`; do ... done, ou encore while read ligne; do .... done < $1, ou encore les tubes. En fait, les sujets ci dessous implémentent tous le schéma algorithmique suivant pour tous les objets i apartenant à une collection d'objets, faire - traiter i - finpour. Ce cadre de développement de programmes est radicalement différent de ce que vous faites en cours Introduction Java où la difficulté réside à décrire des structures et des opérations sur les structures et où, pour faire exister ces structures il suffit de leur appliquer l'opérateur new... et les voila vivant leurs vies.

Ressources pour aller plus loin...