Operativsystem ID hp, ID2200 6hp

Transkript

1 Operativsystem ID hp, ID2200 6hp Robert Rönngren

2 Innehåll Om kursen ID2200 Vad är ett operativsystem och varför ser de ut som de gör? kap , Processer kap. 1.5, 2.1, 2.5 historia och processer 2

3 Om kursen -varför Varför läsa OS? De flesta datorsystem behöver ett OS för att fungera OS:et påverkar vad man kan göra med ett datorsystem, hur det programmeras, prestanda hos applikationerna OS är märkvärdigt långlivade!!! - bra abstraktioner och API - krav på bakåtkompatibilitet historia och processer 3

4 Om kursen mål och krav Mål god förståelse för hur OS - är uppbyggda och fungerar - hur de påverkar applikationer, prestanda etc - kunna dra egna slutsatser utgående från kunskaperna i kursen på egen hand kunna programmera med systemanrop (dvs klara av C-programmering med systemanrop) Krav aktuell laborationskurs Tentamen historia och processer 4

5 Exempeloperativsystem UNIX -> SunOS, Mac OS, Linux, (Windows) LINUX -> Android, Chrome Windows historia och processer 5

6 Om kursen det praktiska (ID2200) Anmälan till kursen på föreläsning 3&4 Maillistor Datorkonton Kursbunt/LabPM? Mail till kursteamet Handledningstider? C-programmering OBLIGATORISK TENTAANMÄLAN VIA DAISY historia och processer 6

7 Hur klarar man kursen? SKAFFA OCH LÄS BOKEN! Tips från tidigare års studenter Börja med labbarna i tid! Labbarna är realistiska programmeringsuppgifter Inte tillrättalagda Realistiska felmöjligheter Inte toy-examples/proof-of-concept Ska lyfta er till en nivå: Lösa enklare civilingenjörsmässiga uppgifter historia och processer 7

8 Professionalism Ni ska ut och jobba om år! Hur mycket är en kurs om 7.5hp värd? Hur ska ni värdera 3 labbrapporter och program? (2 personer * 80 h) Ställ frågor!!!!!!! historia och processer 8

9 Vilka krav ska man ställa på en prestandautvärdering? (jfr lab 3) Mät rätt saker Alldeles för ofta mäter man inte det man tror att man mäter Mätnogrannhet felmarginaler Bör normalt kunna anges Reproducerbarhet Experimenten måste vara sådan och så väl beskrivna att de kan upprepas av någon annan (ett separat PM om utvärderingar är på gång) historia och processer 9

10 Vad är ett operativsystem och varför ser de ut som de gör?

11 Vad är ett operativsystem? (Det program som startas när datorn slås på) Det program som implementerar alla systemanrop Det/de program som exekverar i kernelmode Operativsystemet skall göra datorsystemet användbart för dess ändamål! historia och processer 11

12 Varför ser operativsystem ut som de gör? En liten historisk överblick av dator- och operativsystemens utveckling från 1940-talet och framåt

13 Historia-första generationen Datorer som fyller hela rum (kvarter) Mekaniska reläer och vakumtuber I/O kontrollpanel med switchar/kopplingspanel senare hålkortsläsare Inget OS! Ex: ENIAC, BARK, BESK Bara en användare i taget - otympligt historia och processer 13

14 Återanvändning av kod Måste varje användare skriva all kod från början? Återanvänd kod i form av biblioteksrutiner Kräver Relokerbarhet Länkare Laddare historia och processer 14

15 Historia andra generationen Transistorer tillförlitliga Kommersiella datorer, sk mainframes Hålkort - band Exekvering Band - printer Front-end Mainframe Back-end Batch flera job samlas på band Off-line utskrift av resultat historia och processer 15

16 Historia tredje generationen Integrerade kretsar billigare Mainframes minidatorer (PDP) Operativsystemen viktiga OS/360, MULTICS, UNIX Multiprogrammering Flera jobb samtidigt överlappa I/O med beräkningar Spooling läsa in jobb till kö samtidigt som andra jobb igång Timesharing flera interaktiva användare delar CPU:n historia och processer 16

17 UNIX MULTICS UNIX System V BSD POSIX MINIX LINUX historia och processer 17

18 Historia fjärde generationen 80-nu Ökande integration (kretsar) Superdatorer mikrodatorer (persondatorer) inbyggda datorer Nätverk Persondatorer Användarvänlighet GUI grafiska användargränssnitt CP/M, MS-DOS, WINDOWS historia och processer 18

19 En närmare titt på vad OS gör och hur de organiseras

20 Operativsystem för olika ändamål Olika tillämpningar/plattformar kan ställa speciella krav på operativsystem Speciella OS eller anpassade versioner av mer generella OS för: Stordatorer Servrar Multi-processorer Persondatorer Inbyggda system Realtidssystem Smart-cards historia och processer 20

21 Vad gör ett operativsystem Filsystem (persistent lagring av information) I/O enheter (hantering utan alla detaljer) Processer (virtuella maskiner) Kommunikation Säkerhet, accesskontroll historia och processer 21

22 Ett operativsystem levereras med Kärna Kör i kernel (supervisor) mode Kan ej bytas av enskilda användare Gemensam för alla användare Systemprogram (tcsh, ls, wc,...) Kör i user mode (användarläge) Kan bytas av enskilda användare Ej gemensamma olika användare kör normalt olika instanser av systemprogramvaran historia och processer 22

23 Ett operativsystem kan levereras med Servers (mail, telnet,...) Kör i user mode Kan ej bytas av enskilda användare Gemensamma för alla historia och processer 23

24 Datorsystem Applikationer ex. Webb, spel, administrativa system Editorer Kommandotolk/shell Kompilatorer Operativsystem Systemanrop Säkerhet CPU/Processer Minneshantering Filsystem Kommunikation I/O User space Kernel space Maskininstruktioner Mikroarkitektur Fysiska komponenter historia och processer 24

25 Två vyer av operativsystem? Virtuell (utökad/extended) maskin Isolera program från hårdvaran Bättre programmeringsmodell Portabilitet Resurshanterare Filsystem Minne CPU tid I/O enheter historia och processer 25

26 Operativsystemet som virtuell maskin Kompilator Pascal, C, OZ, ML, Lisp... Assembly Assembler Binärkod med systemanrop Operativsystem Mikroprogram Binärkod utan systemanrop Mikrokod Digital logik historia och processer 26

27 Olika synvinklar på ett operativsystem Användarens bild Kommandon (ls, wc,...) Fönstersystem Programmerarens bild Systemanrop (fork(), exec(),...) Minnesmodell (text, data, stack,...) Implementatörens bild Struktur (monolitiskt, lagrat,...) historia och processer 27

28 Operativsystemsstruktur Monolitisk (vanlig) Lagrad, jfr OSI-modellen, MULTICS, WINDOWS NT Virtuella maskiner, VM-370, Pentium emulerar 8086, JAVA Virtual Machine Mikrokärnor Client-Server modeller MACH, WINDOWS historia och processer 28

29 Systemanrop Hur får vi kontrollen att övergå från user-mode (användarprogram) till kernel-mode (OS)? Systemanrop startas med någon form av TRAP instruktion Koden finns i kärnan Anropande process byter normalt stack tilll en kärnstack och fortsätter exekvera systemanropet i kärnan Exekverar i kernel (supervisor) mode Cirka 100 stycken i Unix (många fler i Windows NT) historia och processer 29

30 count = read (fd, buffer, nbytes) FFFF nbytes buffer 1 stack SP fd R0 read 3 HELLO WORLD data - heap count = read (fd, buffer, nbytes) text - programkod read() 2 read - biblioteksfunktion TRAP 4 OS 5 0 HELLO WORLD historia och processer 30

31 LÄS kap 1.6 bra för labbarna! historia och processer 31

32 Varför har vi valt UNIX som exempelsystem? Ett fleranvändar OS med många användningsområden Öppen källkod Först eller bland de första med många viktiga koncept Har influerat många andra OS (MS-DOS) Enkelt och rent API (systemanrop) Tillgång till vettiga labbmaskiner Används i många industriella applikationer där systemnära eller utveckling av kärnan krävs historia och processer 32

33 Processer En av grundpelarna i operativsystem

34 Program och processer Ett program är en följd av instruktioner En process är ett program under exekvering kod data (stack, heap,...) registerinnehåll fildeskriptorer ytterligare administrativ info historia och processer 34

35 Ett funktionsanrop int main(int argc, char *argv[]) { int tal = 4; printtal(4); } void printtal(int param) { int alokalvariable; printf( tal %d\n, param); } Aktiverings post 1 (stack frame) för main Aktiverings post 2 för PrintTal() Lokala variabler: tal Adress till aktiveringspost 0 Returadress efter main() Parametrar till main(): argv argc Lokala variabler: alokalvariable Adress tilll aktiveringspost 1 Returadress efter printtal: Parametrar till printtal(): param OXFF Hur hittar man returadress och adress till föregående aktiveringspost om man tilllåter ett variabelt antal parametrar som man gör i C? DATA + HEAP TEXT historia och processer 35 OXO

36 Varför processer? Bättre programmeringsmodell många problem hanteras naturligt av processer Bättre feltolerans om en process går ned så behöver inte hela programmet/os:et krascha Möjlighet till bättre resursutnyttjande genom överlappning av CPU-användning och perifera enheter (I/O-enheter) historia och processer 36

37 Att skapa och terminera processer Processer i UNIX skapas med systemanropet fork() Processer fås att exekvera ett nytt program med ett systemanrop ur familjen exec() Processer kan terminera på fyra sätt: Normalt programslut (frivilligt) Med fel som programmet upptäckt (frivilligt) Fatalt fel (ofrivilligt) Dödas av annan process historia och processer 37

38 Process hierarkier Två alternativ: Den process som skapar (föräldraprocessen) associeras med den skapade processen (barnprocessen) på något sätt, ex. UNIX Godtycklig eller ingen association mellan processer (ex. Windows) historia och processer 38

39 Multitasking Multitasking innebär att flera processer exekverar samtidigt En process startar innan föregående avslutar De behöver inte bägge exekvera i samma ögonblick Processerna kan vara Program körda av olika användare vid timesharing Program för samma användare på en arbetsstation eller PC (t.ex. emacs och en kompilator) Systemprocesser historia och processer 39

40 Förgrunds och bakgrundsprocesser i UNIX En process i UNIX kan antingen exekvera i förgrunden vara den som man interaktivt arbetar mot bakgrunden (background) processen exekverar men är inte den man interaktivt arbetar mot Bakgrundsprocesser används för att implementera delar av OS:et, serverprocesser för mail etc. Serverprocesser som exekverar i bakgrunden kallas ofta demoner (daemons) historia och processer 40

41 Processtillstånd RUNNING blockerande systemanrop schemaläggaren beslutar att köra processen BLOCKED preemption något händer, t.ex. I/O klar READY Varför finns inte alla tänkbara tillståndsövergångar med i bilden? historia och processer 41

42 Processtabell Operativsystemet behöver hålla information om processerna i systemet Implementeras i en processtabell Ett entry i processtabellen kallas ofta ProcessControl Block (PCB) Processhantering register programräknare stackpekare register prioritet process id föräldraprocessens PID signaler statistik Minneshantering text data/heap stack Filhantering root directory fildescriptorer User ID Group ID historia och processer 42

43 Frågor Varför går det bra/vill man ofta ha, flera processer igång samtidigt? 100% CPU utnyttjande grad 20% I/O wait 50% I/O wait 80% I/O wait 0 Vilken process skall få exekvera? #processer historia och processer 43

44 Schemaläggning Fördela exekveringstid mellan processer på ett rättvist och effektivt sätt Offline: alla processer är givna i förväg (batch jobb) Online: processer tillkommer kontinuerligt (ex. interaktivt fleranvändarsystem) historia och processer 44

45 Mål för schemaläggning Allmänt Rättvis (fair) Implementera policy Balans alla delar av systemet skall utnyttjas Batchsystem Maximera throughput Minimera turnaroundtid Maximera CPU-utnyttjandegraden Interaktiva system Minimera responstid Proportionalitet möt användarens förväntningar Realtidssystem Klara deadlines Förutsägbarhet historia och processer 45

46 Offline schemaläggning Shortest Job First (SJF) kan användas om man vet processernas exekveringstid i förväg Man tar processerna i ordning från processer med kort exekveringstid till processer med lång tid Om man vill ha en algoritm som ger den kortaste medelsluttiden för processerna är SJF bevisbart optimal historia och processer 46

47 SJF och medelsluttid M Medelsluttid = (3+9)/2=6 Medelsluttid = (6+9)/2=7, historia och processer 47

48 Avbrytande schemaläggning (preemptive scheduling) Exekverande process kan avbrytas utan att ha bett om det (RUNNING READY) Bra om vissa processer är interaktiva men inte nödvändigtvis alla En process avbryts om den kört länge/förbrukat sitt tidskvanta en process med högre prioritet blir körbar (BLOCKED READY) historia och processer 48

49 Schemaläggning med tidsdelning (time-slicing) Alla processer som är READY ligger på readykön När en process har kört en stund, t.ex. 100ms, läggs den sist i ready-kön och den som ligger först får köra i stället Tiden som en process får köra kallas för time slice För bra prestanda krävs rimlig relation mellan time-slice och context-switch (processbytes) tid historia och processer 49

50 Prioriteter Varje process har en prioritet i Unix System V release i original UNIX Processen med högst prioritet får köra (om ej BLOCKED) En process prioritet kan ändras under exekvering Prioriteter anger hur bråttom en process har Ta emot paket från nätet: Bråttom! Kompilera ett program: Inte så bråttom. historia och processer 50

51 Prioriteter och tidsskivning En ready-kö för varje prioritet Processer som använder hela sin time slice utan att bli BLOCKED får lägre prioritet En process som ligger länge i ready-kön får så småningom ökad prioritet för att undvika svältning Kan ge bättre utnyttjande, ökad parallellitet, mellan CPUn och I/O-enheterna historia och processer 51

52 Några ytterligare exempel på schemaläggningsstrategier Round-robin Shortest process next Uppskatta processens längd med längden av nästa CPU-burst (T n+1 ) T n+1 = at n + (1-a)T n-1, 0<= a <= 1 Probabilistisk schemaläggning, lotterischemaläggning historia och processer 52

53 Policy och mekanism Ofta vill man skilja på policy och mekanism Ex: mekanismen är prioritetsschemaläggning policy är hur prioriteter väljs/bestäms historia och processer 53

54 Sammanfattning Applikationer ex. Webb, spel, administrativa system Kommandotolk/shell Editorer Kompilatorer Operativsystem Systemanrop CPU/Processer Minneshantering Maskininstruktioner Mikroarkitektur Fysiska komponenter historia och processer 54

55 Kommande föreläsningar Tors D2: Minneshantering: del 1 Mån D3: Minneshantering: del 2 historia och processer 55