1 Introduction Chapitre 1 Que cest quun SE Développement historique des SE

Ch. 12 Concepts importants du Chapitre 1 Ces concepts seront révisés et précisés pendant le cours n Que cest que un SE n Évolution historique u Par lots u Multiprogrammés u À partage de temps (time-sharing) u Ordis personnels (PCs) u Infonuagique (Cloud Computing) u Parallèles: F Fortement couplés Symétriques, Asymétriques: maître-esclave F Faiblement couplés: Répartis Réseaux n Caractéristiques de matériel et logiciel requises pour cette évolution n Systèmes à temps réel: durs, souples

Ch. 13 Système dexploitation (SE) n Ce que vous voyez et ce que vous ne voyez pas: u Fournit linterface usager/machine: F Masque les détails du matériel aux applications u Contrôle lexécution des applications F Le fait en reprenant périodiquement le contrôle de lUCT F Dit à lUCT quand exécuter tel programme u Optimise l`utilisation des ressources pour maximiser la performance du matériel

Ch. 14 Ressources et leur gestion n Ressources: u Physiques: mémoire vive, unités E/S, UCT... u Logiques = virtuelles: fichiers et bases de données partagés, canaux de communication logiques... u les ressources logiques = virtuelles sont bâties par le logiciel sur les ressources physiques n Allocation de ressources: u gestion de ressources, leur affectation aux usagers qui les demandent, suivant certains critères

Ch. 15 Vue abstraite dun SE

Ch. 16 Pourquoi étudier les SE? n Logiciel très important… u tout programme roule sur un SE u interface usager-ordinateur n Les SE utilisent beaucoup dalgorithmes et structures de données intéressants u Les techniques utilisées dans les SE sont aussi utilisées dans nombreuses autres applications informatiques F il faut les connaître

Ch. 17 Développement de la théorie des SE n La théorie des SE a été développée surtout dans les années 1960 (!!) n A cette époque, il y avait des machines très peu puissantes avec lesquelles on cherchait à faire des applications comparables à celles daujourdhui (mémoire typique: K!) n Ces machines devaient parfois servir des dizaines dusagers! n Dont le besoin de développer des principes pour optimiser lutilisation dun ordinateur. n Principes qui sont encore utilisés

Évolution historique des SE Nous verrons lévolution historique des SE et comment différentes caractéristiques de matériel on été inventées dans cette évolution Ch. 18

9 Évolution historique des SE n Le début: routines d`E/S, amorçage système n Systèmes par lots simples n Systèmes par lots multiprogrammés n Systèmes à partage de temps n Ordinateurs personnels n SE en réseau n SE répartis n Infonuagique (cloud computing)

Ch. 110 Phase 1: Les débuts n Au début, on programmait sur le matériel nu et chaque programme était écrit en langage machine en entier n Puis on a observé quil y avait certaines fonctionnalités qui étaient communes à tous les programmes n Il fallait les pré-programmer et les fournir au programmeur à moyen d`instructions dappel: u amorçage du système (booting sequence) u entrée/sortie ( BIOS)

Ch. 111 Phase 2: Systèmes de traitement par lots (batch) simples n Sont les premiers SE (années mi-1950) n Lusager soumet une job à un opérateur u Programme suivi par données u Pile de carte perforées n Lopérateur place un lot de plusieurs jobs sur le dispositif de lecture cartes n Le SE gère l'exécution de chaque programme du lot n Un seul programme à la fois en mémoire, programmes sont exécutés en séquence n La sortie est normalement sur un fichier, imprimante, ruban magnétique… pas décrans…

Ch. 112 Un ordinateur principal (mainframe) du milieu des annnées 60 Musée de lhistoire de linformatique lecteur de cartes rubans disques UCT (mémoire probablem. autour de K) console opérateur

Ch. 113 Oui, cartes perforées… (figures de Wikipedia) Une ligne de données ou de programme était codée dans des trous qui pouvaient être lus par la machine

Ch. 114 Opérateur lisant un paquet de cartes perforées Source: Finnish Data Processing Museum Association

Principe des systèmes par lots n Pour permettre lexécution automatique des programmes, on soumettait des piles de cartes qui contenaient u Des programmes dusagers u Mélangés avec des instructions pour le SE F JCL, Job Control Language u Pour ce fait, la lecture des cartes doit être faite par lentremise du SE! Ch. 115

Ch. 116 Langage de contrôle des travaux (JCL) n JCL: contrôle lexec d une job u définit le compilateur à utiliser u indique où sont les données n Exemple dune job: u paquet de cartes comme suit: $JOB début de programme $FTN charge le compilateur FORTRAN et compile le programme source $LOAD charge le programme objet (=programme compilé) $RUN transfère le contrôle au programme objet usager n les données sont lues par le SE et passées au progr. usager $JOB $FTN... Programme source FORTRAN... $LOAD $RUN... Données... $END $JOB... (job suivant) Cartes perforées

Ch. 117 Langage de contrôle des travaux (JCL) n LE/S est déléguée au SE n Chaque instruction dE/S dans pgm usager invoque une routine dE/S dans le SE: u sassure de ne pas lire une ligne JCL u un usager ne peu pas interférer avec les E/S d`un autre usager… n Quand le programme usager se termine, la prochaine ligne de JCL est lue et exécutée par le SE

Ch. 118 Le SE par lots n Lecture de cartes perforées n Interprétation de commandes JCL n Lecture (load) dune job (du lecteur de cartes) n Chargement en mémoire (dans la région de lusager) de cette job n Transfère le contrôle au programme usager (job sequencing) n Exécution du programme usager jusquà: u E/S u fin du programme u erreur dexécution n À ces points, le SE reprend le contrôle u Pour le redonner plus tard au même programme ou à un autre programme SE Programme dusager (un à la fois) Contenu de la mémoire

Ch. 119 Caractéristiques désirables du matériel (1) n Protection de la mémoire u Pourquoi? n Minuterie u Pourquoi?

Ch. 120Ch. 120 Caractéristiques désirables du matériel (1) n Protection de la mémoire u ne pas permettre aux pgms usager daltérer la région de la mémoire où se trouve le SE n Minuterie

Ch. 121Ch. 121 Caractéristiques désirables du matériel (1) n Protection de la mémoire u ne pas permettre aux pgms usager daltérer la région de la mémoire où se trouve le SE n Minuterie u limite le temps qu`une job peut exécuter u produit une interruption lorsque le temps est écoulé

Ch. 122 Caractéristiques désirables du matériel (2) n Instructions privilégiées u exécutables seulement par le SE u une interruption se produit lorsquun programme usager tente de les exécuter F UCT peut exécuter en mode superviseur ou mode usager F Les instructions privilégiées ne peuvent être exécutées que en mode superviseur F l usager ne peut exécuter quen mode usager F seulement le SE ou une interruption peuvent changer de mode n Interruptions u facilitent le transfert de contrôle entre le système dexploitation, les opérations d`E/S et les programmes usagers

Ch. 123 Les systèmes « par lots » n Ont été les premiers systèmes d`exploitation. n Ils sont associés aux concepts suivants: u langage de contrôle de travaux (JCL) u système d exploitation résident en mémoire F kernel = noyau u protection de mémoire u instructions privilégiées F modes usager-superviseur u interruptions u minuterie n Toutes ces caractéristiques se retrouvent dans les systèmes daujourdhui

n Dans un système tel que décrit, lUCT est la ressource de lordinateur qui est normalement la moins occupée! Pourquoi ça? Comment chercher à y remédier? Ch. 124

Ch. 125 Phase 2.5: Traitement par lots multiprogrammé n Les opérations E/S sont extrêmement lentes (comparé aux opérations internes) u P. ex. une boucle de programme pourrait durer 10 microsecondes, une opération disque 10 millisecondes F Ordre de F Cest la différence entre 1 heure et 6 semaines! La majorité des programmes passent la majorité de leur temps à attendre lE/S! n Donc: mauvaise utilisation de lUCT lorsquun seul pgm usager se trouve en mémoire [Stallings]

Ch. 126 Traitement par lots multiprogrammé n Si la mémoire peut contenir +sieurs pgms, lUCT peut exécuter un autre pgm lorsquun pgm attend après E/S n Cest la multiprogrammation [Stallings]

Ch. 127 Plusieurs programmes en mémoire pour la multiprogrammation

Ch. 128Ch. 128 Exigences pour multiprogrammation n Interruptions n Pourquoi?

Ch. 129Ch. 129 Exigences pour multiprogrammation n Interruptions F Redonne le contrôle au SE F Qui pourra donner lUCT à un autre travail F Nous verrons: ordonnancement dUCT n Protection de la mémoire: n Pourquoi?

Ch. 130 Exigences pour multiprogrammation n Interruptions F afin de pouvoir exécuter dautres jobs lorsquun job attend après E/S n Protection de la mémoire: isole les jobs n Gestion du matériel F plusieurs jobs prêts à être exécutées demandent des ressources: UCT, mémoire, unités E/S n Langage pour gérer lexécution des travaux: interface entre usager et SE u jadis JCL, maintenant shell, command prompt ou semblables

Ch. 131 Spoule ou spooling n Au lieu dexécuter les travaux au fur et à mesure quils sont lus, les stocker sur une mémoire secondaire (disque) n Puis choisir quels programmes exécuter et quand u Ordonnanceur à long terme, à discuter F Exemple typique: spoule de limprimante

Ch. 132 Équilibre de travaux n S`il y a un bon nombre de travaux à exécuter, on peut chercher à obtenir un équilibre n Travaux qui utilisent peu l`UCT, beaucoup l E/S, sont appelés tributaires de l`E/S n Nous parlons aussi de travaux tributaires de l UCT n Le temps d`UCT non utilisé par des travaux trib. de lE/S peut être utilisé par des travaux trib. de l UCT et vice-versa. n Lobtention d`un tel équilibre est le but des ordonnanceurs à long terme et à moyen terme (à discuter). n Dans les systèmes de multiprog. on a souvent coexistence de travaux longs et pas urgents avec travaux courts et urgents u Le SE donne priorité aux deuxièmes et exécute les premiers quand il y a du temps de machine disponible.

Équilibre de travaux n Plus simplement, un système est équilibré sil y a assez de travaux dans les deux catégories pour garder occupé tant les UCT que les unités dE/S: u Travaux tributaires de lUCT u Travaux tributaires de lE/S Ch. 133

Ch. 134 Phase 3: Systèmes à temps partagé (TSS) ordinateur principal (mainframe) Terminaux stupides

Ch. 135 Systèmes à temps partagé (TSS) n Le traitement par lots multiprogrammé ne supporte pas linteraction avec les usagers u excellente utilisation des ressources mais frustration des usagers! n TSS permet à la multiprogrammation de desservir plusieurs usagers simultanément n Le temps dUCT est partagé par plusieurs usagers n Les usagers accèdent simultanément et interactivement au système à laide de terminaux

Principe de partage de temps n Supposons quil y a un outil coûteux à disposition de tous n Chacun sen sert pour 15 minutes dans une heure, puis le retourne à sa place n Combien dusagers pourront utiliser cet outil? Ch. 136

Ch. 137 Systèmes à temps partagé (TSS) n TSS: Time-Sharing Systems n Le temps de réponse humain est lent: supposons qu`un usager nécessite, en moyenne, 2 sec du processeur par minute dutilisation n Environ 30 usagers peuvent donc utiliser le système sans délais notable du temps de réaction de lordinateur n Les fonctionnalités du SE dont on a besoin sont les mêmes que pour les systèmes par lots, plus u la communication avec usagers u le concept de mémoire virtuelle pour faciliter la gestion de mémoire u traitement central des données des usagers (partagées ou non)

Ch. 138 Ordinateurs Personnels (PCs) n Peuvent agir isolés ou en réseau u ordinateur de réseau (network computer), u infonuagique (cloud computing) u donc extension des principes des TSS.

Ch. 139 Aujourdhui Ordinateur principal (mainframe ou serveur) Terminaux intelligents (PCs)

Ch. 140 Retour aux concepts de TSS n Plusieurs PC (clients) peuvent être servis par un ordi plus puissant (serveur) pour des services qui sont trop complexes pour eux (clients/serveurs, bases de données, telecom) n Les grands serveurs utilisent beaucoup des concepts développés pour les systèmes TSS

Infonuagique (cloud computing) Ch. 141 Ch. 1 Plusieurs serveurs servent plusieurs communauté dusagers Les applications sont dans le nuage Le nuage est géré par une entreprise tel que Google, Microsoft … ou aussi votre université (nuage local) terminaux stupides

Systèmes multiprocesseurs Ch. 142

Ch. 143 Systèmes multiprocesseurs n De plus en plus communs u Processeurs à double, quadruple … cœur Plusieurs UCT pour une seule mémoire F Les ordinateurs partagent mémoire, horloge, etc. u Si un ordi a 3 coeurs, cad 3 UCT, les temps de traitement de 3 travaux peuvent être superposés (pas seulement les temps dE/S) UCT Mém …

Ch. 144Ch. 144 Considérations sur systèmes multiprocesseurs n Est-ce-que 2, 3… UCT ont un rendement 2, 3… fois supérieur à une seule UCT?

Ch. 145 Considérations sur systèmes multiprocesseurs n Est-ce-que 2, 3… UCT ont un rendement 2, 3… fois supérieur à une seule UCT? u Moins que ça, car les UCT doivent passer du temps à synchroniser, se passer des données F Voir loi dAmdahl (Amdahls law, infos sur le www) n À terme, le petit coût des puces rendra possible des systèmes avec des dizaines, voire centaines dUCT n Économies u Plusieurs processeurs peuvent partager les périphériques, la mémoire, lalimentation électrique… n Plus de fiabilité car si une UCT tombe en panne, les autres peuvent se partager sa tâche u Dégradation harmonieuse, tolérance aux pannes

Ch. 146 Fonctionnement des systèmes multiprocesseurs n Symétrique u Les différentes UCT se partagent les travaux sans préférences u La solution la plus normalement utilisée n ou Asymétrique u Chaque UCT est dédiée à un certain type de travail. n À revoir: Chapitre 6

Systèmes répartis Ch. 147

Ch. 148 Systèmes distribués ( = répartis) n Les systèmes répartis fournissent: u partage de fichiers (systèmes client-serveur) u patrons de communication (protocoles) u autonomie des usagers sur leurs ordinateurs n Linfonuagique est un cas particulier des systèmes repartis u Toute lintelligence est dans le nuage u Le nuage est géré par un fournisseur de services

Ch. 149 Systèmes distribués ( = répartis) n Deux solutions principales: u Les systèmes multiprocesseurs sont faiblement couplés (loosely coupled) F consistent dordinateurs autonomes, qui communiquent à travers lignes de communication u Il y a un seul SE qui exécute à travers un ensemble de machines qui sont reliées par un réseau (strongly coupled) F Approprié pour certaines applications seulement

Systèmes à temps réel et s. embarqués Ch. 150

Ch. 151 Systèmes à temps réel n Doivent réagir à ou contrôler des événements externes (p.ex. contrôler une usine). Les délais de réaction doivent être bornés n systèmes temps réel souples: u les échéances sont importantes, mais ne sont pas critiques (p.ex. systèmes téléphoniques) n systèmes temps réel rigides (hard): u le échéances sont critiques, p.ex. F contrôle dune chaîne d`assemblage F graphiques avec animation n (ma déf. de souple nest pas la même que dans le livre)

Systèmes embarqués=embedded systems n Les systèmes embarqués sont des systèmes qui sont inclus dans un système plus gros qui les utilise n Ce dernier système est souvent un système mécanique u Ordinateurs dans voitures (freins, injection etc.) u Appareils photo, montres, téléphones …. u Systèmes de guide davions, navires … n Ils sont préprogrammés et spécialisés n Ils sont des systèmes en temps réel n Domaine dapplication rapidement grandissant Ch. 152

Synthèse historique Ch. 153

Ch. 154 Évolution des SE

Ch Une synthèse historique Ordinateurs Personn. Mainframes et grands serveurs Différents SE (1960s) Unix (1970) MS-DOS (1981) Windows (1990) Linux (1991) Windows NT (1988) Windows XP (2001) Vista (2007) System 7 (2009) System 8 (2012) Solaris (1995) Mac/OS (1984) Android (2005) Systèmes Mobiles Mainframe Linux (2000) Multics (1965)

Ch. 156 Concepts importants du Chapitre 1 n Que cest que un SE n Évolution historique u Par lots u Multiprogrammés – balance de travaux u À partage de temps (time-sharing) u Parallèles: F Fortement couplés Symétriques, Asymétriques: maître-esclave F Faiblement couplés: Répartis Réseaux n Caractéristiques de matériel et logiciel requises pour cette évolution n Systèmes à temps réel: durs, souples

Ch. 157 Dans le manuel, pour ce chapitre n Lire le chapitre entier u Excepté les sections 1.6, 1.7, 1.9, 1.11qui sont intéressantes mais pas sujet dexamen

Ch. 158 Ch. 158 MULTICS, UNIX, Linux n MULTICS a été un système TSS très sophistiqué pour son époque n Développé à lMIT n Années 196X n Ne réussit pas à cause de la faiblesse du matériel de son époque (mémoire vive 300K!) n Quelques unes de ses idées furent reprises dans le système UNIX n Développé à Bell Labs n Années 197X n Plus tard UNIX fut programmé pour les PC et devint Linux n Développé par Linus Torvalds et beaucoup dautres n Années 199X n Malgré lapparence de changements continus, les concepts au cœur dun SE comme Android aujourdhui sont des clairs descendants des concepts au cœur dUnix il y a quarante ans.

Mémoire vive n Chaque ordi a une mémoire vive, dite aussi: u RAM (Random Access Memory) u Mémoire centrale u Mémoire principale … n LUnité Centrale est connectée directement à cette mémoire n Afin que des données puissent être élaborées par lUCT, ils doivent être dans la mémoire vive n Les autres mémoires sappellent périphériques ou auxiliaires n Les opérations entre les mémoires secondaires et la mémoire vive sont des opérations dentrée-sortie u E/S, I/O Ch. 159

RAM, ROM n Bien que les acronymes RAM et ROM se rassemblent, il dénotent des choses différentes n RAM Random Access Memory est la mémoire centrale dun ordi u Random veut dire quon peut y accéder aléatoirement, sans ordre spécifique n ROM Read Only Memory est une mémoire qui ne peut quêtre lue u On y met les données au moment où elle est fabriquée et elles ne peuvent pas être modifiées F P.ex. le programme bootstrap = amorçage peut être en ROM u Certaines parties de la mémoire RAM dun ordi peuvent être utilisées comme ROM F P.ex. le vecteur dinterruptions et la séquence boot amorce dun ordinateur sont normalement dans la partie ROM de la mémoire RAM Ch. 160

Ch. 161 Terminologie: mémoire centrale et auxiliaire n Le cache est étroitement lié à la mémoire vive ou centrale, donc il est considéré partie de cette dernière u Sauf que encore une fois lUCT ne peut pas opérer directement sur le cache n Mémoires auxiliaires sont toutes les autres mémoires dans le système u Disques u Flash-memory u Rubans… n Les mémoires auxiliaires sont des périphériques

Ch. 162 Terminologie n Opérations dE/S: Entrée ou Sortie, Input/Output u Les opérations de lecture ou écriture en ou de mémoire centrale u Peuvent être directement ou indirectement demandées par le programme F Exemple dindirectement: E/S occasionnées par la pagination u Entrée: F Read dans un programme Lecture de disque Caractères lu du clavier Click du souris Lecture de courriel Lecture de page web (à être affichée plus tard, p.ex.) u Sortie: F Write dans un programme Affichage sur lécran Impression Envoi de courriel Sortie de page web demandée par une autre machine

Ch. 163 Terminologie n Travaux en lots (batch) u Travaux non-urgents qui sont soumis au système pour ramasser la réponse plus tard F Tri de fichier, calcul dune fonction complexe, grosses impressions, sauvegarde régulière de fichiers usagers F Pour plus defficacité, peuvent être groupés et exécutés les uns après les autres n Interactifs u Sont les travaux qui demandent une interaction continue avec lordinateur: F Édition de documents ou dun programme n Les premiers ordinateurs navaient pas de mécanismes de communication aisée entre usager et machine, donc normalement les travaux étaient par lots

Quelques comparaisons historiques n Mémoire typique dun des premiers ordis avec SE: approx. 300K (possiblement 250K) u Vers 1965 un ordi comme ça aurait été très grand et dispendieux. u Probablement il y en avait seulement quelques uns dans notre région n Mémoire typique dun PC aujourdhui: 3G: fois plus grande. n Cest la même relation entre u Terrain pour maison typique, disons 3 000m 2 = 60m x 50m u fois plus grand est 30M de m 2 u = 30Km 2 = 6km x 5km, cest la dimension dun village Ch. 164

Ch. 165 Comment programmer ça? Comment programmer ça? n Les informaticiens daujourdhui sont souvent surpris du fait quon pouvait faire quelque chose dutile avec des ordinateurs aussi petits que ceux qui existaient dans les années 60 n Un exemple pourra aider à comprendre...

Ch. 166 Un programme Bonjour Monde du début des années #T OXXXXXX0 BONJOUR MONDE Ce programme consiste en 29 octets ( en langage machine ) Son adresse initiale est 0. La première ligne dit dimprimer à partir de ladresse 16 pour longueur 13. La deuxième ligne est linstruction STOP. La 3ème ligne est la constante à imprimer Le programme fait tout le travail, aucun SE, aucun BIOS …

Ch. 167 Programmes Hello World daujourdhui class HelloWorld { public static void printHello( ) { System.out.println("Hello, World"); } } class UseHello { public static void main(String[ ] args) { HelloWorld myHello = new HelloWorld( ); myHello.printHello( ); } } class Message { String messageBody; public void setMessage(String newBody) { messageBody = newBody; } public String getMessage( ) { return messageBody; } public void printMessage( ) { System.out.println(messageBody); } public class MyFirstProgram { public static void main(String[ ] args) { Message mine = new Message ( ); mine.setMessage("Hello, World"); Message yours = new Message ( ); yours.setMessage("This is my first program!"); mine.printMessage( ); System.out.println(yours.getMessage( ) + "" + mine.getMessage( ) ); } Dans larticle: C. Hu. Dataless objects considered harmful. Comm. ACM 48 (2), lauteur présente deux versions orientées objet de programmes Hello World. Il critique la version ci-dessous disant quelle nest pas vraiment orientée objet et quil faudrait vraiment utiliser la version à droite. Quelle est la mémoire demandée par ces programmes? Il serait intéressant de voir...