1 Introduction Chapitre 1 Que c’est qu’un SE Développement historique des SE

Présentation au sujet: "1 Introduction Chapitre 1 Que c’est qu’un SE Développement historique des SE"— Transcription de la présentation:

1 1 Introduction Chapitre 1 Que c’est qu’un SE Développement historique des SE http://w3.uqo.ca/luigi/

2 Ch. 12 Concepts importants du Chapitre 1 Ces concepts seront révisés et précisés pendant le cours n Que c’est 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) n Caractéristiques de matériel et logiciel requises pour cette évolution n Systèmes à temps réel: durs, souples

3 Ch. 13 Système d’exploitation (SE) n Ce que vous voyez et ce que vous ne voyez pas: u Fournit l’interface usager/machine: F Masque les détails du matériel aux applications u Contrôle l’exécution des applications F Le fait en reprenant périodiquement le contrôle de l’UCT F Dit aux UCT quand exécuter tel programme u Optimise l`utilisation des ressources pour maximiser la performance du matériel n Malgré les différences d’un SE à l’autre, les principes présentés dans ce cours se trouvent dans tous les SE!

4 Ch. 14 Ressources et leur gestion n Ressources: u Physiques: UCT, mémoire vive, unités E/S... 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

5 Ch. 15 Vue abstraite d’un SE

6 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 d’algorithmes 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

7 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 d’aujourd’hui (mémoire typique: 250-500K!) n Ces machines devaient parfois servir des dizaines d’usagers! n Dont le besoin de développer des principes pour optimiser l’utilisation d’un ordinateur. n Principes qui sont encore utilisés

8 Important: Type de système à considérer n Bien que les SE roulent sur tout ordi, aujourd’hui leur efficacité est essentielle seulement pour les systèmes très chargés u P.ex. serveurs web ou de grandes entreprises F Google, Yahoo, Amazon, banques … n Donc pour bien apprécier la matière de ce cours, vous devriez penser aux conditions de travail de ces grands systèmes u Pas tellement à ce qui se passe dans votre ordi Ch. 18

9 Point de réflexion n Google roule des millions d’ordinateurs, qui fonctionnent à pleine charge! n Et utilisent tous le même SE n Une amélioration (ou perte) d’efficacité de seulement 1% de ce SE peut sauver (ou coûter) à Google des millions de $! u Bonne gestion de l’UCT, bonne gestion de la mémoire … Ch. 19

10 É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. 110

11 Ch. 111 É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)

12 Ch. 112 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é qu’il 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 d’appel: u amorçage du système (booting sequence) u entrée/sortie (  BIOS)

13 Ch. 113 Phase 2: Systèmes de traitement par lots (batch) simples n Sont les premiers SE (années mi-1950) n L’usager soumet une job à un opérateur u Pile de carte perforées u Programme suivi par données n L’opé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…

14 Ch. 114 Un ordinateur principal (mainframe) du milieu des annnées ‘60 Musée de l’histoire de l’informatique http://www.computerhistory.org/ lecteur de cartes rubans disques UCT (mémoire probablem. autour de 250-500K) console opérateur

15 Ch. 115 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

16 Ch. 116 Opérateur lisant un paquet de cartes perforées Source: http://www.tietokonemuseo.saunalahti.fi/eng/kuva_32_eng.htm http://www.tietokonemuseo.saunalahti.fi/eng/kuva_32_eng.htm Finnish Data Processing Museum Association

17 Principe des systèmes par lots n Pour permettre l’exécution automatique des programmes, on soumettait des piles de cartes qui contenaient u Des programmes d’usagers 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 l’entremise du SE! Ch. 117

18 Ch. 118 Langage de contrôle des travaux (JCL) n JCL: contrôle l’exec des jobs u définit le compilateur à utiliser u indique où sont les données n Exemple d’une job: u paquet de cartes comme suit: $JOB début de la job $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... Cartes de programme source FORTRAN... $LOAD $RUN... Cartes de données... $END $JOB... (job suivante) Cartes perforées

19 Ch. 119 Langage de contrôle des travaux (JCL) n L’E/S est déléguée au SE n Chaque instruction d’E/S dans pgm usager invoque un programme d’E/S dans le SE: u s’arrête à la prochaine 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

20 Ch. 120 Le SE par lots n Lecture de cartes perforées n Interprétation de commandes JCL n Lecture (load) d’une job (du lecteur de cartes) n Chargement en mémoire (dans la région de l’usager) 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 d’exécution n À ces points, le SE reprend le contrôle u Pour le redonner plus tard au même programme ou à au prochain programme SE Programme d’usager (un à la fois) Contenu de la mémoire

21 Ch. 121 Caractéristiques désirables du matériel n Interruption n Instructions privilégiées n Protection de la mémoire u Pourquoi? n Minuterie u Pourquoi?

22 Ch. 122 Caractéristiques désirables du matériel (2) n Interruptions u facilitent le transfert de contrôle entre le système d’exploitation, les opérations d`E/S et les programmes usagers n Instructions privilégiées et modes d’exécution u exécutables seulement par le SE u une interruption se produit lorsqu’un 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 qu’en mode usager F seulement le SE ou une interruption peuvent changer de mode

23 Ch. 123Ch. 123 Caractéristiques désirables du matériel (1) n Protection de la mémoire u ne pas permettre aux pgms usager d’alté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é

24 Ch. 124 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 d’aujourd’hui

25 MAIS …. Dans un système tel que décrit, l’UCT est la ressource de l’ordinateur qui est normalement la moins occupée! Pourquoi ça? Comment chercher à y remédier? Ch. 125

26 Ch. 126 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 1 000 F C’est la différence entre 1 heure et 6 semaines! La majorité des programmes passent la majorité de leur temps à attendre l’E/S! n Donc: mauvaise utilisation de l’UCT lorsqu’un seul pgm usager se trouve en mémoire [fig. de Stallings]

27 Ch. 127 Traitement par lots multiprogrammé n Si la mémoire peut contenir +sieurs pgms, l’UCT peut exécuter un autre pgm lorsqu’un pgm attend après E/S n C’est la multiprogrammation [fig. de Stallings]

28 Ch. 128 Plusieurs programmes en mémoire pour la multiprogrammation !!

29 Ch. 129Ch. 129 Exigences pour multiprogrammation n Interruptions n Pourquoi?

30 Ch. 130Ch. 130 Exigences pour multiprogrammation n Interruptions F Redonne le contrôle au SE F Qui pourra donner l’UCT à un autre travail F Nous verrons: ordonnancement d’UCT n Protection de la mémoire: n Pourquoi?

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

32 Ch. 132 Spoule ou spooling n Au lieu d’exécuter les travaux au fur et à mesure qu’ils 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 l’imprimante

33 Ch. 133 É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 l’E/S peut être utilisé par des travaux trib. de l ’UCT et vice-versa. n L’obtention d`un tel équilibre est le but des ordonnanceurs à long terme et à moyen terme (à discuter).

34 Équilibre de travaux n Plus simplement, un système est équilibré s’il y a assez de travaux dans les deux catégories pour garder occupé tant les UCT que les unités d’E/S: u Travaux tributaires de l’UCT u Travaux tributaires de l’E/S Ch. 134

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

36 Ch. 136 Systèmes à temps partagé (TSS) n Le traitement par lots multiprogrammé ne supporte pas l’interaction 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 d’UCT est partagé par plusieurs usagers n Les usagers accèdent simultanément et interactivement au système à l’aide de terminaux

37 Principe de partage de temps n Supposons qu’il y a un outil coûteux à disposition de tous n Chacun s’en sert pour 15 minutes dans une heure, puis le retourne à sa place n Combien d’usagers pourront utiliser cet outil? Ch. 137

38 Ch. 138 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 d’utilisation n Environ 30 usagers peuvent donc utiliser le système sans délais notable du temps de réaction de l’ordinateur 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)

39 Ch. 139 Phase 4: Ordinateurs Personnels avec serveurs 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.

40 Ch. 140 Aujourd’hui Ordinateur principal (mainframe ou serveur) Terminaux ‘intelligents’ (PCs)’

41 Ch. 141 Évolution des concepts de TSS n Plusieurs PC (clients) peuvent être servis par un ordi plus puissant (serveur) pour des services qui exigent un ordi dédié (clients/serveurs, bases de données, telecom)

42 Infonuagique (cloud computing) Ch. 142 Plusieurs serveurs servent plusieurs communauté d’usagers Les applications sont dans le nuage Le nuage est géré par une entreprise tel que Google, Microsoft … ou aussi votre université (nuage local)

43 Systèmes multiprocesseurs Ch. 143

44 Ch. 144 Systèmes multiprocesseurs (multi-cœurs) 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 d’E/S) UCT Mém …

45 Ch. 145Ch. 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? n Nous verrons …

46 Ch. 146 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 d’Amdahl’ (Amdahl’s law, infos sur le www) n À terme, le petit coût des puces rendra possible des systèmes avec des centaines d’UCT n Économies u Plusieurs processeurs peuvent partager les périphériques, la mémoire, l’alimentation é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

47 Ch. 147 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

48 Systèmes répartis Ch. 148

49 Ch. 149 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 L’infonuagique est un cas particulier des systèmes repartis u Toute l’intelligence est dans le ‘nuage’ u Le nuage est géré par un fournisseur de services

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

51 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, c.a.d. les retards dégradent le système mais ne sont pas critiques F systèmes téléphoniques F graphiques avec animation n systèmes temps réel rigides (hard): u le échéances sont critiques, c.a.d. les retards sont inacceptables, p.ex. F conduite de voiture ou avion F contrôle d’une chaîne d`assemblage

52 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 d’avions, navires … n Ils sont préprogrammés et spécialisés n Ils sont des systèmes en temps réel n Domaine d’application rapidement grandissant Ch. 152

53 Synthèse historique Ch. 153

54 Ch. 154 Évolution des SE cloud

55 Ch. 1 55 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)

56 Ch. 156 Concepts importants du Chapitre 1 n Que c’est que un SE n Évolution historique u Par lots u Multiprogrammés – balance de travaux u À partage de temps (time-sharing) n Caractéristiques de matériel et logiciel requises pour cette évolution n Systèmes à temps réel: durs, souples

57 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 d’examen

58 Ch. 158 Ch. 158 MULTICS, UNIX, Linux n MULTICS a été un système TSS très sophistiqué pour son époque n Développé à l’MIT avec la compagnie General Electric n Années 196X n Ne réussit pas à cause de la faiblesse du matériel de son époque (mémoire principale 300K!) n Quelques unes des idées de Multics 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 autres n Années 199X n Malgré l’apparence de changements continus, les concepts du noyau de Android aujourd’hui dérivent des concepts du noyau d’Unix n Les Mac-Apple OS sont aussi basés sur les mêmes concepts n Windows est un développement indépendant (Bill Gates) mais enfin il utilise en bonne partie les mêmes concepts

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

60 RAM, ROM n Bien que les acronymes RAM et ROM se rassemblent, il dénotent des concepts très différents n RAM Random Access Memory est la mémoire centrale d’un ordi u Random veut dire qu’on 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 d’un ordi peuvent être utilisées comme ROM F P.ex. le vecteur d’interruptions et la séquence boot ‘amorce’ d’un ordinateur sont normalement dans la partie ROM de la mémoire RAM Ch. 160

61 Vol de cycles ou Cycle stealing n Comment les opérations d’E/S peuvent-elles exécuter en même temps que les programmes? n La plupart des ordis disposent d’un mécanisme appelé ‘vol de cycles’ n Avec ce mécanisme, on permet au bus d’E/S de ‘voler’ occasionnellement des cycles d’UCT ou de mémoire centrale pour effectuer de ops comme p.ex. mettre en mémoire centrale un octet reçu d’une unité disque u Ceci retarde l’UCT mais de manière minimale Ch. 161

62 Ch. 162 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 l’UCT 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

63 Ch. 163 Terminologie n Opérations d’E/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 d’indirectement: 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

64 Ch. 164 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 d’une fonction complexe, grosses impressions, sauvegarde régulière de fichiers usagers F Pour plus d’efficacité, 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 l’ordinateur: F Édition de documents ou d’un programme n Les premiers ordinateurs n’avaient pas de mécanismes de communication aisée entre usager et machine, donc normalement les travaux étaient ‘par lots’

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

66 Ch. 166 Comment programmer ça? Comment programmer ça? n Les informaticiens d’aujourd’hui sont souvent surpris du fait qu’on pouvait faire quelque chose d’utile avec des ordinateurs aussi petits que ceux qui existaient dans les années ’60 n Un exemple pourra aider à comprendre...

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

68 Ch. 168 Programmes Hello World d’aujourd’hui 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 l’article: C. Hu. Dataless objects considered harmful. Comm. ACM 48 (2), 99-101 http://portal.acm.org/citation.cfm?id=1042091.1042126# l’auteur présente deux versions orientées objet de programmes ‘Hello World’. Il critique la version ci-dessous disant qu’elle n’est pas vraiment orientée objet et qu’il faudrait vraiment utiliser la version à droite. Quelle est la mémoire demandée par ces programmes? Il serait intéressant de voir...

69 Une curiosité historique n Pourquoi les « disques durs » sont appelés comme ça? Ch. 169

70 Une curiosité historique n Pourquoi les « disques durs » sont appelés comme ça? n Car à une époque on avait les « disque souples », désormais complètement désuets! n À noter que cette image est aussi utilisés pour le symbole ‘enregistrement’ de plusieurs logiciels! Ch. 170