Samtidige prosesser. Prosessor modus. Hvordan kan OS effektivt kontrollere brukerprosesser? Hvordan kan OS. kontrollere brukerprosesser?

Transkript

1 Samtidige To (tasks) må ikke ødelegge for hverandre: skrive til samme minne kapre for mye CPU-tid få systemet til å henge Beste løsning: All makt til OS = Preemptive multitasking Preemptive = rettighetsfordelende. Opprinnelig betydning: Preemption = Myndighetene fordeler landområde.

2 Alle moderne prosessorer har et modusbit som kan begrense hva som er lov å gjøre. Modusbit switcher mellom bruker og priviligert modus Kalles også protection hardware og er nødvendig for å kunne kjøre multitasking. Bruker modus: User mode. Begrenset aksess av minne og instruksjoner; må be OS om tjenester. Priviligert modus : Kernel mode. Alle instruksjoner kan utføres. Alt minne og alle registere kan aksesseres.

3 Problem: OS kan ikke tillate en prosess/bruker å ta kontroll over maskinen. Men hvis OS skal hver instruksjon en bruker-prosess utfører (emulering) gir veldig mye systemoverhead.

4 Problem: OS kan ikke tillate en prosess/bruker å ta kontroll over maskinen. Effektiv løsning: OS bruker en hardware timer til å gi et begrenset tidsintervall til en brukerprosess switcher til brukermodus og laster inn 1. brukerinstruksjon. Når tiden er ute, hopper CPU til OS-kode og OS overtar.

5 Tilgjengelig fra brukermodus Brukerdata og program Bruker minne Tilgjengelig fra priviligert modus OS System Software Bruker til kjernen OS kjernen Priviligert minne Figure: Modusbit må switches til priviligert/kernel modus for å kunne kjøre kode fra priviligert del av minne (OS-kjernen). Deler av OS ligger utenfor kjernen og kan kjøres fra brukermodus.

6 Brukerkode ber kjernen om hjelp ved Med en instruksjon SWITCH TO KERNELMODE, kunne et program fra usermodus ta over Hvordan løse dilemmaet: sette modusbit til kernel og deretter være sikker på at det kun er kjernekode som kjøres? Må igjen ha hjelp fra hardware i form av en spesiell instruksjon, trap trap switcher til kernelmode og hopper til kode for i en operasjon

7 Bruker kode INS1 INS2 INS3.. TRAP 3 INS8... Bruker minne S Modus bit Branching tabell OS kjernen Syscall 1: (sys_exit) Syscall 2: (sys_fork) 4. Syscall 3: (sys_read) priviligert minne Figure: Trap-instruksjonen sørger for at en brukerprosess ikke kan oppnå full kontroll over en maskin ved å switche til kernelmodus.

8 Address 0xFFFFFFFF Return to caller Trap to the kernel 5 Put code for read in register 4 10 Library procedure read User space Increment SP Call read Push fd Push &buffer Push nbytes 11 9 User program calling read Kernel space (Operating system) Dispatch 7 8 Sys call handler 0 Figure: Tanenbaums illustrasjon av et read-.

9

10 Figure: Tanenbaums på fra Unix og.

11 Tiden deles i epoker Hver prosess tildeles et time-quantum målt i et helt antall jiffies(=ticks) som legges i variabelen counter. Time-quantum: F. eks. 20 i enheter av ticks = 10 ms = timer-intervall OS kjører så Round Robin-scheduling. Prosessen som kjører mister ett tick for hvert timer-tick. For hvert timer-tick sjekkes det om kjørende prosess har flere ticks, counter > 0 Hvis counter > 0 fortsetter prosessen, hvis ikke kalles schedule() som velger en ny

12 Epoken er over når alle har brukt opp sin tid (counter = 0) Antall ticks som deles ut før hver epoke bestemmes av prioriteten og lagres i en variabel med navn priority En vanlig brukerprosess kan senke sin egen prioritet kan dermed endres dynamisk (har en prosess brukt mye CPU, kan den f. eks. få nedsatt prioritet) Gjennomsnittlig time-quantum for 2.4 kjernen var 210 ms Gjennomsnittlig time-quantum for 2.6 kjernen er ca 100 ms

13 Linux 2.6 kjernen deler dynamisk prosessene inn i 140 forkjellige prioritetsklasser. Hver prioritetsklasse tilsvarer et antall tildelte ticks i starten av en epoke. Hver gang scheduleren kalles, velges prosessen som har høyest prioritet. Kjører til den har brukt opp alle sine tildelte ticks. Deretter kalles scheduleren på nytt.

14 Hvis det i løpet av epoken kommer et interrupt, vil et flagg need_resched bli satt Scheduler vil på grunn av dette kjøres etter neste timer-tick. Interaktive prosessen gis dynamisk høy prioritet og får dermed bedre responstid Ellers måtte de vente helt til en kjørende CPU-intensiv prosess var ferdig med alle sine ticks i en epoke