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

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

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

2 Concepts importants du Chapitre 1
Ces concepts seront révisés et précisés pendant le cours Que c’est que un SE Évolution historique Par lots Multiprogrammés À partage de temps (time-sharing) Ordis personnels (PCs) Infonuagique (Cloud Computing) Caractéristiques de matériel et logiciel requises pour cette évolution Systèmes à temps réel: durs, souples Ch. 1

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

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

5 Vue abstraite d’un SE Ch. 1

6 Développement de la théorie des SE
La théorie des SE a été développée surtout dans les années 1960 (!!) 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: K!) Ces machines devaient parfois servir des dizaines d’usagers! Dont le besoin de développer des principes pour optimiser l’utilisation d’un ordinateur. Principes qui sont encore utilisés Ch. 1

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

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

9 É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. 1

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

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

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

13 Un ordinateur principal (mainframe) du milieu des annnées ‘60
disques UCT (mémoire probablem. autour de K) rubans lecteur de cartes console opérateur Ch. 1 Musée de l’histoire de l’informatique

14 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. 1

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

16 Principe des systèmes par lots
Pour permettre l’exécution automatique des programmes, on soumettait des piles de cartes qui contenaient Des programmes d’usagers Mélangés avec des instructions pour le SE JCL, Job Control Language Pour ce fait, la lecture des cartes doit être faite par l’entremise du SE! Ch. 1

17 Langage de contrôle des travaux (JCL)
Cartes perforées JCL: contrôle l’exec des jobs définit le compilateur à utiliser indique où sont les données Exemple d’une job: 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 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 suivante) Ch. 1

18 Langage de contrôle des travaux (JCL)
L’E/S est déléguée au SE Chaque instruction d’E/S dans pgm usager invoque un programme d’E/S dans le SE: s’arrête à la prochaine ligne JCL un usager ne peu pas interférer avec les E/S d`un autre usager… Quand le programme usager se termine, la prochaine ligne de JCL est lue et exécutée par le SE Ch. 1

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

20 Caractéristiques désirables du matériel
Interruption Instructions privilégiées Protection de la mémoire Pourquoi? Minuterie Ch. 1

21 Caractéristiques désirables du matériel (2)
Interruptions pour le transfert de contrôle entre le système d’exploitation, les opérations d`E/S et les processus usagers Instructions privilégiées et modes d’exécution exécutables seulement par le SE une interruption se produit lorsqu’un processus usager tente de les exécuter UCT peut exécuter en mode superviseur ou mode usager Les instructions privilégiées ne peuvent être exécutées que en mode superviseur l ’usager ne peut exécuter qu’en mode usager seulement le SE ou une interruption peuvent changer de mode Ch. 1

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

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

24 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. 1

25 Phase 2.5: Traitement par lots multiprogrammé
Les opérations E/S sont extrêmement lentes (comparé aux opérations internes) P. ex. une boucle de programme pourrait durer 5 microsecondes, une opération disque 5 millisecondes Ordre de 1 000 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! Donc: mauvaise utilisation de l’UCT lorsqu’un seul pgm usager se trouve en mémoire Ch. 1 [fig. de Stallings]

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

27 Plusieurs programmes en mémoire pour la multiprogrammation
!! Ch. 1

28 Exigences pour multiprogrammation
Interruptions Pourquoi? Ch. 1 Ch. 1 28

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

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

31 Spoule ou spooling Au lieu d’exécuter les travaux au fur et à mesure qu’ils sont lus, les stocker sur une mémoire secondaire (disque) Puis choisir quels programmes exécuter et quand Ordonnanceur à long terme, à discuter Exemple typique: spoule de l’imprimante Ch. 1

32 Équilibre de travaux S`il y a un bon nombre de travaux à exécuter, on peut chercher à obtenir un équilibre Travaux qui utilisent peu l`UCT, beaucoup l ’E/S, sont appelés tributaires de l`E/S Nous parlons aussi de travaux tributaires de l’UCT 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. L’obtention d`un tel équilibre est le but des ordonnanceurs à long terme et à moyen terme (à discuter). Ch. 1

33 Équilibre de travaux 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: Travaux tributaires de l’UCT Travaux tributaires de l’E/S Ch. 1

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

35 Systèmes à temps partagé (TSS)
Le traitement par lots multiprogrammé ne supporte pas l’interaction avec les usagers excellente utilisation des ressources mais frustration des usagers! TSS permet à la multiprogrammation de desservir plusieurs usagers simultanément Le temps d’UCT est partagé par plusieurs usagers Les usagers accèdent simultanément et interactivement au système à l’aide de terminaux Ch. 1

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

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

38 Phase 4: Ordinateurs Personnels avec serveurs
Peuvent agir isolés ou en réseau ordinateur de réseau (network computer), infonuagique (cloud computing) donc extension des principes des TSS. Ch. 1

39 Terminaux ‘intelligents’ (PCs)’
Jusqu’à récemment Terminaux ‘intelligents’ (PCs)’ Ordinateur principal (mainframe ou serveur) Ch. 1

40 Évolution des concepts de TSS
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) Ch. 1

41 Aujourd’hui: Infonuagique (cloud computing)
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) Ch. 1

42 Serveurs …. Ch. 1

43 Réseaux d’équipements mobiles
Les réseaux informatiques d’aujourd’hui sont des réseaux d’équipements de types et fonctionnement différents, incluant entre autres des téléphones cellulaires Cependant presque tous les SE continuent à être basés sur les principes de Linux, avec ses racines beaucoup plus anciennes Ch. 1

44 Systèmes multiprocesseurs
Ch. 1

45 Systèmes multiprocesseurs (multi-cœurs)
Normal aujourd’hui Processeurs à double, quadruple … cœur Plusieurs UCT pour une seule mémoire Les ordinateurs partagent mémoire, horloge, etc. 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 UCT UCT Mém Ch. 1

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

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

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

49 Systèmes répartis Ch. 1

50 Systèmes distribués ( = répartis)
Les systèmes répartis fournissent: partage de fichiers (systèmes client-serveur) patrons de communication (protocoles) autonomie des usagers sur leurs ordinateurs L’infonuagique est un cas particulier des systèmes repartis Toute l’intelligence est dans le ‘nuage’ Le nuage est géré par un fournisseur de services Ch. 1

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

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

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

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

55 Dans le manuel, pour ce chapitre
Lire le chapitre entier Excepté les sections 1.6, 1.7, 1.9, 1.11qui sont intéressantes mais pas sujet d’examen Ch. 1

56 MATÉRIAUX SUPPLÉMENTAIRES
Ch. 1

57 Synthèse historique Ch. 1

58 Évolution des SE cloud Ch. 1

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

60 MULTICS, UNIX, Linux MULTICS a été un système TSS très sophistiqué pour son époque Développé à l’MIT avec la compagnie General Electric Années 196X Ne réussit pas à cause de la faiblesse du matériel de son époque (mémoire principale 300K!) Quelques unes des idées de Multics furent reprises dans le système UNIX Développé à Bell Labs Années 197X Plus tard UNIX fut programmé pour les PC et devint Linux Développé par Linus Torvalds et autres Années 199X Malgré l’apparence de changements continus, les concepts du noyau de Android aujourd’hui dérivent des concepts du noyau d’Unix Les Mac-Apple OS sont aussi basés sur les mêmes concepts Windows est un développement indépendant (Bill Gates) mais enfin il utilise en bonne partie les mêmes concepts Ch. 1 60 Ch. 1

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

62 RAM, ROM Bien que les acronymes RAM et ROM se rassemblent, il dénotent des concepts très différents RAM Random Access Memory est la mémoire centrale d’un ordi Random veut dire qu’on peut y accéder aléatoirement, sans ordre spécifique ROM Read Only Memory est une mémoire qui ne peut qu’être lue On y met les données au moment où elle est fabriquée et elles ne peuvent pas être modifiées P.ex. le programme ‘bootstrap’ = amorçage peut être en ROM Certaines parties de la mémoire RAM d’un ordi peuvent être utilisées comme ROM 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. 1

63 Vol de cycles ou Cycle stealing
Comment les opérations d’E/S peuvent-elles exécuter en même temps que les programmes? La plupart des ordis disposent d’un mécanisme appelé ‘vol de cycles’ 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 Ceci retarde l’UCT mais de manière minimale Ch. 1

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

65 Terminologie Opérations d’E/S: Entrée ou Sortie, Input/Output
Les opérations de lecture ou écriture en ou de mémoire centrale Peuvent être directement ou indirectement demandées par le programme Exemple d’indirectement: E/S occasionnées par la pagination Entrée: 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.) Sortie: Write dans un programme Affichage sur l’écran Impression Envoi de courriel Sortie de page web demandée par une autre machine Ch. 1

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

67 Terminologie Les mode ‘superviseur’ et ‘usager’ de l’UCT sont appelés de plusieurs manières équivalentes: Mode kernel, mode noyau. mode superviseur, mode maître (master) Mode ‘esclave’… Ch. 1

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

69 Un exemple pourra aider à comprendre...
Comment programmer ça? 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 Un exemple pourra aider à comprendre... Ch. 1

70 Un programme Bonjour Monde du début des années ‘60
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 … Ch. 1

71 Programmes Hello World d’aujourd’hui
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( ) ); 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( );    } } Dans l’article: C. Hu. Dataless objects considered harmful. Comm. ACM 48 (2), 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... Ch. 1

72 Une curiosité historique
Pourquoi les « disques durs » sont appelés comme ça? Ch. 1

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