Prosessledelse (databehandling) - Process management (computing)

En prosess er et program i utførelse. En integrert del av ethvert moderne operativsystem (OS). Operativsystemet må tildele ressurser til prosesser , gjøre det mulig for prosesser å dele og utveksle informasjon, beskytte ressursene til hver prosess mot andre prosesser og muliggjøre synkronisering mellom prosesser. For å oppfylle disse kravene, må operativsystemet opprettholde en datastruktur for hver prosess, som beskriver tilstanden og ressurs eierskapet til den prosessen, og som gjør det mulig for OS å utøve kontroll over hver prosess.

Multiprogrammering

I ethvert moderne operativsystem kan det være mer enn en forekomst av et program lastet i minnet samtidig. For eksempel kan mer enn én bruker utføre det samme programmet, hver bruker har separate kopier av programmet lastet inn i minnet. Med noen programmer er det mulig å ha en kopi lastet inn i minnet, mens flere brukere har delt tilgang til den slik at de kan utføre den samme programkoden. Et slikt program sies å være med på nytt . Den prosessor i ethvert øyeblikk bare kan utføre én instruksjon fra ett program, men mange prosesser kan opprettholdes over en tidsperiode ved å tildele hver enkelt prosess for prosessoren i intervaller, mens det resterende blir midlertidig inaktive. En rekke prosesser som utføres over en periode i stedet for samtidig kalles samtidig utføring .

Et flerprogrammerings- eller multitasking- operativsystem er et system som utfører mange prosesser samtidig. Multiprogrammering krever at prosessoren tildeles hver prosess i en periode og avdeles på et passende tidspunkt. Hvis prosessoren blir de-allokert under utførelsen av en prosess, må det gjøres på en slik måte at den kan startes på nytt så enkelt som mulig.

Det er to mulige måter for et operativsystem å gjenvinne kontrollen over prosessoren under utførelsen av et program for at operativsystemet skal utføre tildeling eller tildeling:

  1. Prosessen utsteder et systemkall (noen ganger kalt en software interrupt ); for eksempel oppstår en I / U-forespørsel som ber om å få tilgang til en fil på harddisken.
  2. En maskinvareavbrudds inntreffer; for eksempel ble en tast trykket på tastaturet, eller en tidtaker løper ut (brukes i forebyggende multitasking ).

Stopp av en prosess og start (eller omstart) av en annen prosess kalles en kontekstbryter eller kontekstendring. I mange moderne operativsystemer kan prosesser bestå av mange delprosesser. Dette introduserer konseptet med en tråd . En tråd kan sees på som en underprosess ; det vil si en egen, uavhengig sekvens av utførelse innenfor koden til en prosess. Trådene blir stadig viktigere i utformingen av distribuerte og klient-server- systemer og i programvare som kjøres på flerprosessorsystemer .

Hvordan flerprogrammering øker effektiviteten

Et vanlig trekk observert blant prosesser assosiert med de fleste dataprogrammer, er at de veksler mellom CPU- sykluser og I / O- sykluser. For den delen av tiden som kreves for CPU-sykluser, blir prosessen utført; dvs. okkuperer CPU. I løpet av tiden som kreves for I / O-sykluser, bruker prosessen ikke prosessoren. I stedet venter den enten på å utføre Input / Output, eller utfører faktisk Input / Output. Et eksempel på dette er lesing fra eller skriving til en fil på disken. Før advent av multiprogramming , datamaskiner drives som enkeltbrukersystemer. Brukere av slike systemer ble raskt oppmerksomme på at prosessoren var inaktiv i mye av tiden at en datamaskin ble tildelt en enkelt bruker. når brukeren for eksempel skrev inn informasjon eller feilsøkingsprogrammer. Dataforskere observerte at maskinens samlede ytelse kunne forbedres ved å la en annen prosess bruke prosessoren når en prosess ventet på input / output. I et uni-programmeringssystem , hvis N- brukere skulle utføre programmer med individuelle kjøringstider på t 1 , t 2 , ..., t N , så er den totale tiden, t uni , for å betjene N- prosessene (fortløpende) av alle N brukere vil være:

t uni = t 1 + t 2 + ... + t N .

Imidlertid, fordi hver prosess bruker både CPU-sykluser og I / O-sykluser, er tiden som hver prosess faktisk bruker CPUen, en veldig liten brøkdel av den totale gjennomføringstiden for prosessen. Så for prosess i :

t i (prosessor) ≪ t i (utførelse)

hvor

t i (prosessor) er den tid prosessen jeg bruker ved hjelp av CPU, og
t i (utførelse) er den totale utførelsestiden for prosessen; dvs. tiden for CPU-sykluser pluss I / O-sykluser som skal utføres (utføres) til prosessen er fullført.

Faktisk overstiger vanligvis summen av all prosessortid, brukt av N- prosesser, sjelden en liten brøkdel av tiden for å utføre en av prosessene;

Derfor, i uni-programmeringssystemer, lå prosessoren på tomgang en betydelig del av tiden. For å overvinne denne ineffektiviteten implementeres multiprogrammering nå i moderne operativsystemer som Linux , UNIX og Microsoft Windows . Dette gjør at prosessoren kan bytte fra en prosess, X, til en annen, Y, når X er involvert i I / O-fasen av utførelsen. Siden behandlingstiden er mye mindre enn en enkelt jobbs kjøretid, kan den totale tiden til å betjene alle N- brukere med et flerprogrammeringssystem reduseres til omtrent:

t multi = maks ( t 1 , t 2 , ..., t N )

Prosessoppretting

Operativsystemer trenger noen måter å lage prosesser på. I et veldig enkelt system designet for kun å kjøre en enkelt applikasjon (f.eks. Kontrolleren i en mikrobølgeovn), kan det være mulig å ha alle prosessene som noen gang vil være behov for å være til stede når systemet kommer opp. I generelle systemer er det imidlertid behov for en eller annen måte å opprette og avslutte prosesser etter behov under drift.
Det er fire hovedhendelser som får en prosess til å opprettes:

  • Systeminitialisering.
  • Utføring av prosessopprettingssystemanrop ved en pågående prosess.
  • En brukerforespørsel om å opprette en ny prosess.
  • Igangsetting av en batchjobb.

Når et operativsystem startes opp, opprettes vanligvis flere prosesser. Noen av disse er forgrunnsprosesser, som samhandler med en (menneskelig) bruker og utfører arbeid for dem. Andre er bakgrunnsprosesser , som ikke er knyttet til bestemte brukere, men i stedet har en bestemt funksjon. For eksempel kan en bakgrunnsprosess være utformet for å akseptere innkommende e-postmeldinger, sove mesteparten av dagen, men plutselig våkne til liv når en innkommende e-post kommer. En annen bakgrunnsprosess kan være utformet for å godta en innkommende forespørsel om websider som er vert på maskinen, og våkne når en forespørsel kommer til å betjene forespørselen.

Prosessoppretting i UNIX og Linux gjøres gjennom fork () eller klon () systemanrop. Det er flere trinn involvert i prosessoppretting. Det første trinnet er validering av om foreldreprosessen har tilstrekkelig autorisasjon til å opprette en prosess. Etter vellykket validering blir foreldreprosessen kopiert nesten helt, med bare endringer i den unike prosess-ID, foreldreprosess og brukerrom. Hver nye prosess får sin egen brukerplass.

Prosessavslutning

Det er mange grunner til avslutning av prosessen:

  • Batchjobbproblemer stopper instruksjonene
  • Bruker logger av
  • Prosess utfører en tjenesteforespørsel om å avslutte
  • Feil- og feilforhold
  • Normal ferdigstillelse
  • Tidsgrensen overskredet
  • Minne utilgjengelig
  • Grenser brudd; for eksempel: forsøkt tilgang til (ikke-eksisterende) 11. element i et 10-element array
  • Beskyttelsesfeil; for eksempel: forsøkte å skrive til skrivebeskyttet fil
  • Aritmetisk feil; for eksempel: forsøk på deling med null
  • Tid overskredet; for eksempel: prosessen ventet lenger enn et spesifisert maksimum for en hendelse
  • I / O- feil
  • Ugyldig instruksjon; for eksempel når en prosess prøver å utføre data (tekst)
  • Privilegert instruksjon
  • data misbruk
  • Operasjonssystemintervensjon ; for eksempel: å løse en fastlåst situasjon
  • Foreldre avsluttes slik at barneprosesser avsluttes (cascading termination)
  • Foreldreforespørsel

To-statlig prosessstyringsmodell

Det operativsystem finnes prinsipalt er ved styring av utførelsen av prosesser . Dette inkluderer å bestemme flettemønsteret for utførelse og tildeling av ressurser til prosesser. En del av utformingen av et operativsystem er å beskrive atferden vi ønsker at hver prosess skal vises. Den enkleste modellen er basert på at en prosess enten blir utført av en prosessor eller ikke. Dermed kan en prosess anses å være i en av to tilstander, RUNNING eller NOT RUNNING . Når operativsystemet oppretter en ny prosess, blir den prosessen først merket som IKKE RUNNING , og plasseres i en kø i systemet i IKKE RUNNING- tilstand. Prosessen (eller en del av den) eksisterer da i hovedminnet , og den venter i køen til en mulighet skal utføres. Etter en viss periode vil den nåværende KJØRING- prosessen bli avbrutt, og flyttes fra RUNNING- tilstanden til IKKE RUNNING- tilstand, noe som gjør prosessoren tilgjengelig for en annen prosess. Utsendelsesdelen av operativsystemet vil deretter velge en av venteprosessene som skal overføres til prosessoren , fra køen IKKE RUNNING- prosesser. Den valgte prosessen blir deretter ommerket fra en IKKE KJØRENDE tilstand til en KJØRENDE tilstand, og kjøringen av den blir enten startet hvis det er en ny prosess, eller gjenopptas hvis det er en prosess som ble avbrutt på et tidligere tidspunkt.

Fra denne modellen kan vi identifisere noen designelementer i operativsystemet:

  • Behovet for å representere og holde oversikt over hver prosess.
  • Tilstanden til en prosess.
  • Køen av IKKE RUNNING- prosesser

Tre-statlig prosessstyringsmodell

Selv om prosessadministrasjonsmodellen med to tilstander er et perfekt gyldig design for et operativsystem, betyr fraværet av en BLOKERT tilstand at prosessoren ligger inaktiv når den aktive prosessen endres fra CPU-sykluser til I / U- sykluser. Denne designen gjør ikke effektiv bruk av prosessoren. Tre-status prosessadministrasjonsmodellen er designet for å løse dette problemet, ved å innføre en ny stat kalt BLOCKED state. Denne tilstanden beskriver enhver prosess som venter på at en I / O-hendelse skal finne sted. I dette tilfellet kan en I / O-hendelse bety bruk av en enhet eller et signal fra en annen prosess. De tre tilstandene i denne modellen er:

  • KJØRING: Prosessen som utføres for øyeblikket.
  • KLAR: En prosess som står i kø og forberedt på å utføre når den får muligheten.
  • BLOKERT: En prosess som ikke kan utføres før en hendelse inntreffer, for eksempel fullføringen av en I / O-operasjon.

Når som helst er en prosess i en og bare en av de tre tilstandene. For en enkelt prosessormaskin kan bare én prosess være i KJØRING- tilstand på et øyeblikk. Det kan være mange prosesser i tilstandene KLAR og BLOKERT , og hver av disse tilstandene vil ha en tilhørende kø for prosesser.

Prosesser som kommer inn i systemet, må først gå i KLAR tilstand, prosesser kan bare gå inn i KJØRING- tilstand via KLAR . Prosesser forlater normalt systemet fra RUNNING- tilstand. For hver av de tre tilstandene opptar prosessen plass i hovedminnet. Selv om årsaken til de fleste overganger fra en stat til en annen kan være åpenbar, kan det hende at noen ikke er så klare.

  • KJØRING → KLAR Den vanligste årsaken til denne overgangen er at kjøringsprosessen har nådd maksimalt tillatt tid for uavbrutt kjøring; dvs. time-out oppstår. Andre årsaker kan være innføringen av prioritetsnivåer som bestemt av planleggingspolitikken som brukes for lavnivåplanleggeren , og ankomsten av en høyere prioritetsprosess til KLAR.
  • KJØRING → BLOKKERT En prosess settes i BLOKKERT tilstand hvis den ber om noe den må vente på. En forespørsel til operativsystemet er vanligvis i form av en systemanrop, (dvs. en samtale fra den kjørende prosessen til en funksjon som er en del av OS-koden). For eksempel å be om en fil fra disk eller lagre en del av kode eller data fra minne til en fil på disk.

Prosessbeskrivelse og kontroll

Hver prosess i systemet er representert av en datastruktur kalt en Process Control Block (PCB), eller Process Descriptor i Linux , som utfører samme funksjon som et reisendes pass. PCB inneholder grunnleggende informasjon om jobben, inkludert:

  • Hva det er
  • Hvor det skal
  • Hvor mye av behandlingen er fullført
  • Hvor den er lagret
  • Hvor mye det har “brukt” på å bruke ressurser

Prosessidentifikasjon : Hver prosess er unikt identifisert av brukerens identifikasjon og en peker som kobler den til beskrivelsen.

Prosessstatus : Dette indikerer gjeldende status for prosessen; KLAR , LØPENDE , BLOKERT , KLAR SUSPEND , BLOKKERT SUSPEND .

Prosesstilstand : Dette inneholder all informasjonen som trengs for å indikere den nåværende tilstanden til jobben.

Regnskap : Dette inneholder informasjon som hovedsakelig brukes til faktureringsformål og til måling av ytelse. Den indikerer hva slags ressurser prosessen har brukt og hvor lenge.

Prosessormodus

Moderne prosessorer har en modusbit for å definere kjøringsevnen til et program i prosessoren. Denne biten kan settes til kjernemodus eller brukermodus . Kjernemodus er også ofte referert til som overordnet modus , skjermmodus eller ring 0 .

I kjernemodus kan prosessoren utføre alle instruksjoner i maskinvarerepertoaret, mens det i brukermodus bare kan utføre et delsett av instruksjonene. Instruksjoner som bare kan kjøres i kjernemodus kalles kjerne-, privilegerte eller beskyttede instruksjoner for å skille dem fra brukermodusinstruksjonene. For eksempel er I / O- instruksjoner privilegerte. Så, hvis en søknad Programmet kjører i brukermodus, det kan ikke ha en egen I / O . I stedet må det be OS om å utføre I / O på vegne av det.

Den datamaskinarkitektur kan logisk forlenge modusbiten for å definere områder av minne som skal benyttes når prosessoren er i kjernemodus som funksjon av brukermodus. Hvis modusbiten er satt til kjernemodus, kan prosessen som kjøres i prosessoren få tilgang til enten kjernen eller brukerpartisjonen til minnet. Imidlertid, hvis brukermodus er angitt, kan prosessen bare referere til brukerens minne. Vi refererer ofte til to klasser av brukerbrukerplass og systemplass (eller kjerne, veileder eller beskyttet plass). Generelt utvider modusbiten operativsystemets beskyttelsesrettigheter. Modusbiten er angitt av brukerinstruksjonsinstruksjonen, også kalt en veiledningsanvisning . Denne instruksjonen setter modusbit og forgrener seg til et fast sted i systemområdet. Siden bare systemkode er lastet inn i systemområdet, kan bare systemkode påberopes via en felle. Når operativsystemet har fullført veilederanropet, tilbakestiller det modusbiten til brukermodus før retur.

Kernelsystemkonseptet

Delene av operativsystemet som er avgjørende for riktig drift, kjøres i kjernemodus , mens annen programvare (for eksempel generisk systemprogramvare) og alle applikasjonsprogrammer kjøres i brukermodus . Dette grunnleggende skillet er vanligvis det ugjendrivelige skillet mellom operativsystemet og annen systemprogramvare . Den delen av systemet som kjøres i kjerneovervåkningstilstand, kalles kjernen eller kjernen til operativsystemet . Kjernen fungerer som pålitelig programvare, noe som betyr at når den ble designet og implementert, var den ment å implementere beskyttelsesmekanismer som ikke kunne skjules forandret gjennom handlingene til ikke-klarert programvare som kjøres i brukerområdet. Utvidelser til operativsystemet kjøres i brukermodus , slik at operativsystemet ikke er avhengig av riktigheten til de delene av systemprogramvaren for riktig drift av operativsystemet. Derfor er en grunnleggende designbeslutning for enhver funksjon som skal innlemmes i operativsystemet om den må implementeres i kjernen. Hvis den er implementert i kjernen, vil den kjøres i kjerneområdet (veileder) og ha tilgang til andre deler av kjernen. Det vil også være klarert programvare av de andre delene av kjernen. Hvis funksjonen er implementert for å kjøres i brukermodus , vil den ikke ha tilgang til kjernedatastrukturer. Fordelen er imidlertid at det normalt vil kreve svært begrenset innsats for å påkalle funksjonen. Mens kjerneimplementerte funksjoner kan være enkle å implementere, er felle-mekanismen og autentisering på tidspunktet for samtalen vanligvis relativt dyr. Kjernekoden kjører fort, men det er store ytelsesomkostninger i selve samtalen. Dette er et subtilt, men viktig poeng.

Ber om systemtjenester

Det er to teknikker som et program som kjøres i brukermodus kan be om kjernetjenester :

Operativsystemer er designet med det ene eller det andre av disse to fasilitetene, men ikke begge deler. Anta først at en brukerprosess ønsker å påkalle en bestemt målsystemfunksjon. For systemanropstilnærmingen bruker brukerprosessen felleinstruksjonen. Tanken er at systemanropet skal se ut til å være en vanlig prosedyreanrop til applikasjonsprogrammet; den OS gir et bibliotek av brukerfunksjoner med navn som svarer til hver selve systemkall. Hver av disse stubfunksjonene inneholder en felle til OS-funksjonen. Når applikasjonsprogrammet kaller stubben, utfører den felleinstruksjonen, som bytter CPU til kjernemodus , og deretter forgrener seg (indirekte gjennom en OS-tabell), til inngangspunktet til funksjonen som skal påkalles. Når funksjonen er fullført, bytter den prosessoren til brukermodus og returnerer deretter kontrollen til brukerprosessen; og simulerer dermed en normal prosedyreretur.

I meldingsoverføringstilnærmingen konstruerer brukerprosessen en melding som beskriver ønsket tjeneste. Deretter bruker den en klarert sendefunksjon for å overføre meldingen til en klarert OS- prosess . Send-funksjonen tjener samme formål som fellen; det vil si at den nøye sjekker meldingen, bytter prosessoren til kjernemodus og deretter leverer meldingen til en prosess som implementerer målfunksjonene. I mellomtiden venter brukerprosessen på resultatet av tjenesteforespørselen med en melding motta operasjon. Når OS-prosessen fullfører operasjonen, sender den en melding tilbake til brukerprosessen.

Skillet mellom to tilnærminger har viktige konsekvenser med hensyn til OS-atferdens relative uavhengighet fra applikasjonsprosessens atferd og den resulterende ytelsen. Som en tommelfingerregel kan operativsystem basert på et systemanropsgrensesnitt gjøres mer effektivt enn det som krever at meldinger skal utveksles mellom forskjellige prosesser. Dette er tilfelle, selv om systemanropet må implementeres med en felleinstruksjon; det vil si, selv om fellen er forholdsvis kostbare å utføre, er det mer effektivt enn den meldingsutveksling tilnærming, hvor det er generelt høyere kostnader forbundet med prosess -multipleksing , meldingsdannelse og meldings kopiering. Systemanropstilnærmingen har den interessante egenskapen at det ikke nødvendigvis er noen OS-prosess. I stedet endres en prosess som kjøres i brukermodus til kjernemodus når den kjører kjernekode, og bytter tilbake til brukermodus når den kommer tilbake fra OS-samtalen. Hvis operativsystemet derimot er utformet som et sett med separate prosesser, er det vanligvis lettere å utforme det slik at det får kontroll over maskinen i spesielle situasjoner, enn om kjernen bare er en samling funksjoner utført av brukere prosesser i kjernemodus. Selv prosedyrebasert operativsystem finner det vanligvis nødvendig å inkludere minst noen få systemprosesser (kalt demoner i UNIX ) for å håndtere situasjoner der maskinen ellers er inaktiv, for eksempel planlegging og håndtering av nettverket.

Se også

Referanser

  1. ^ "En sniktitt på Linux-kjernen - kapittel 2: prosessoppretting"

Kilder

  • Operativsystem som inneholder Windows og UNIX, Colin Ritchie. ISBN   0-8264-6416-5
  • Operativsystemer, William Stallings, Prentice Hall, (4. utgave, 2000)
  • Multiprogrammering, prosessbeskrivelse og kontroll
  • Operativsystemer - Et moderne perspektiv, Gary Nutt, Addison Wesley, (2. utgave, 2001).
  • Prosessadministrasjonsmodeller, planlegging, UNIX System V versjon 4:
  • Moderne operativsystemer, Andrew Tanenbaum, Prentice Hall, (2. utgave, 2001).
  • Operativsystemkonsepter, Silberschatz & Galvin & Gagne ( http://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/ ), John Wiley & Sons, (6. utgave, 2003)