Hva betyr antall tråder i en prosessor? Prosesser og tråder

8.2.1. Enkle konsepter

Operativsystemet Windows 2000 støtter tradisjonelle prosesser som kan kommunisere og synkronisere med hverandre på samme måte som UNIX-prosesser gjør. Hver prosess inneholder minst én tråd, som igjen inneholder minst én fiber (lett tråd). Dessuten kan prosesser kombineres til jobber for å administrere spesifikke ressurser. Sammen danner jobber, prosesser, tråder og fibre et felles sett med verktøy for å administrere ressurser og implementere parallellitet på både enkeltprosessor- og multiprosessormaskiner.

Trening i Windows 2000, en samling av én eller flere prosesser som administreres som en enkelt enhet. Spesielt har hver jobb tilknyttet kvoter og ressursgrenser, som lagres i det tilsvarende jobbobjektet. Kvoter inkluderer elementer som maksimalt antall prosesser (hindrer jobbprosesser fra å opprette et ukontrollert antall underordnede prosesser), den totale CPU-tiden som er tilgjengelig for hver prosess individuelt og for alle prosesser sammen, samt den maksimale mengden minne som brukes for prosessen og for hele jobben. Jobs kan også begrense prosessene deres av sikkerhetsmessige årsaker, for eksempel å hindre dem i å få administratorrettigheter (superbruker) selv om de har riktig passord.

Som i UNIX-systemet, prosesser er beholdere for ressurser. Hver prosess har en 4-gigabyte adresseplass, der brukeren opptar de nederste 2 GB (i Windows 2000 Advanced Server og Datacenter Server kan denne størrelsen valgfritt økes til 3 GB) og operativsystemet opptar resten. Dermed er operativsystemet til stede i adresserommet til hver prosess, selv om det er beskyttet mot endringer av maskinvare-MMU. En prosess har en prosess-ID, en eller flere tråder, en liste over håndtak (administrert i kjernemodus) og et tilgangstoken som lagrer sikkerhetsinformasjon. Prosesser opprettes ved hjelp av et Win32-kall som bruker navnet på en kjørbar fil som spesifiserer det opprinnelige innholdet i adresserommet og oppretter en første tråd.

Hver prosess starter med en enkelt tråd, men nye tråder kan opprettes dynamisk. Strømmer danne grunnlaget for CPU-planlegging fordi operativsystemet alltid velger en tråd i stedet for en prosess som skal kjøres. Følgelig har hver tråd en tilstand (klar, kjører, blokkert, etc.), mens prosesser ikke har tilstander. Tråder kan opprettes dynamisk av et Win32-kall som gis startadressen til utførelse i prosessens adresserom. Hver tråd har en tråd-ID hentet fra samme plass som prosess-ID-er, så den samme ID-en vil aldri bli brukt for både en prosess og en tråd. Prosess- og tråd-ID-er er multipler av fire, så de kan brukes som byteindekser i kjernetabeller, akkurat som andre objekter.

Vanligvis kjører en tråd i brukermodus, men når den foretar et systemanrop, bytter den til kjernemodus, hvoretter den fortsetter å kjøre den samme tråden, med de samme egenskapene og restriksjonene som den hadde i brukermodus. Hver tråd har to stabler - en brukt i kjernemodus og den andre i brukermodus. I tillegg til stat, ID og to stabler, har hver tråd en kontekst (som lagrer registrene når de ikke kjører), et privat område for lokale variabler, og kan også ha sitt eget tilgangstoken. Hvis en tråd har sitt eget tilgangstoken, overstyrer den prosessens tilgangstoken slik at klienttråder kan overføre tilgangsrettighetene sine til servertråder som jobber for dem. Når en tråd er ferdig med arbeidet, kan den slutte å eksistere. Når den siste aktive tråden slutter å eksistere, avsluttes prosessen.

Det er viktig å forstå at tråder er et planleggingskonsept, ikke et ressurseierskapskonsept. Enhver tråd kan få tilgang til alle objekter i prosessen. Alt han trenger å gjøre for å gjøre dette er å ta tak og foreta den riktige Win32-kallingen. Det er ingen begrensninger på en tråds tilgang til et objekt basert på om objektet ble opprettet eller åpnet av en annen tråd. Systemet holder ikke engang styr på hvilket objekt som ble opprettet av hvilken tråd. Når et objekthåndtak er plassert i en prosess håndtakstabell, kan enhver tråd i prosessen bruke det.

I tillegg til de vanlige trådene som kjører i brukerprosesser, har Windows 2000-operativsystemet mange daemon-prosesser som ikke er assosiert med noen brukerprosess (de er assosiert med et spesielt system eller inaktive prosesser). Noen demoner utfører administrative oppgaver, for eksempel å skrive skitne (modifiserte) sider til disken, mens andre danner et basseng og kan brukes av kjøretidskomponenter eller drivere som trenger å utføre noen asynkrone oppgaver på disken. bakgrunn. Å bytte tråder i Windows 2000 tar ganske lang tid fordi det krever å bytte til kjernemodus og deretter gå tilbake til brukermodus. For å gi svært lettvekts pseudo-parallellisme, bruker Windows 2000 fibre, ligner på tråder, men planlagt i brukerområdet av programmet (eller dets kjøretidssystem) som opprettet dem. Hver tråd kan ha flere fibre, akkurat som en prosess kan ha flere tråder, med den forskjellen at når en fiber er logisk blokkert, plasseres den i en kø av blokkerte fibre, hvoretter en annen fiber i sammenheng med samme tråd velges. å løpe. Operativsystemet vet ikke om endringen av fibre, siden den samme tråden fortsetter å fungere. Siden operativsystemet ikke vet noe om fibre, i motsetning til jobber, prosesser og tråder, er det ingen utførelsessystemobjekter knyttet til dem. Det er ingen reelle systemanrop for å kontrollere fibre. Det er imidlertid Win32 API-kall for dette. De refererer til de Win32 API-kallene som ikke foretar systemanrop.

Merk at Windows 2000-operativsystemet kan kjøre på symmetriske multiprosessorsystemer. Dette betyr at koden operativsystem må være fullstendig reentrant, det vil si at hver prosedyre må skrives på en slik måte at to eller flere sentrale prosessorer kan endre variablene sine uten problemer. I mange tilfeller betyr dette at programseksjoner må beskyttes ved hjelp av spinlocks eller mutexes, som holder ekstra CPUer i standby-modus til den første CPUen har fullført arbeidet (ved bruk av sekvensiell tilgang til kritiske områder).

Den øvre grensen på 32 CPUer er en hard grense fordi mange steder i operativsystemet bruker 32-bits bitmaps i ordstørrelse for å ta hensyn til CPU-bruk. For eksempel brukes et enkelt ord punktgrafikk for å holde styr på hvilke sentrale behandlingsenheter fri inn dette øyeblikket, og en annen array brukes i hver prosess for å liste CPU-ene som den prosessen tillates å kjøre på. 64-biters versjonen av Windows 2000 skal kunne støtte opptil 64 CPUer uten mye innsats. Å overskride denne grensen vil kreve betydelig omarbeiding av programmet (ved å bruke flere ord for punktgrafikk).

• Opplæringen

I denne artikkelen vil jeg prøve å beskrive terminologien som brukes for å beskrive systemer som er i stand til å kjøre flere programmer parallelt, det vil si multi-core, multi-prosessor, multi-threaded. Forskjellige typer parallellitet i IA-32 CPU dukket opp i annen tid og i en noe inkonsekvent rekkefølge. Det er ganske lett å bli forvirret i alt dette, spesielt med tanke på at operativsystemer nøye skjuler detaljer fra mindre sofistikerte applikasjonsprogrammer.

Formålet med artikkelen er å vise at med alle mulige konfigurasjoner av multiprosessor, multi-core og multi-threaded systemer, skapes muligheter for programmer som kjører på dem både for abstraksjon (ignorere forskjeller) og for å ta hensyn til spesifikke ( muligheten til å programmere finne ut konfigurasjonen).

Advarsel om ®, ™ tegn i artikkelen

Min kommentar forklarer hvorfor bedriftsansatte bør bruke opphavsrettsmerknader i offentlig kommunikasjon. I denne artikkelen måtte jeg bruke dem ganske ofte.

prosessor

Selvfølgelig er det eldste, mest brukte og kontroversielle begrepet "prosessor".

I den moderne verden er en prosessor noe vi kjøper i en vakker detaljboks eller en ikke så fin OEM-pakke. En udelelig enhet satt inn i en stikkontakt på hovedkort. Selv om det ikke er noen kontakt og den ikke kan fjernes, det vil si at hvis den er tett loddet, er det én brikke.

Mobilsystemer (telefoner, nettbrett, bærbare datamaskiner) og de fleste stasjonære datamaskiner har én prosessor. Arbeidsstasjoner og servere har noen ganger to eller flere prosessorer på ett enkelt hovedkort.

Å støtte flere CPUer i et enkelt system krever en rekke designendringer. Som et minimum er det nødvendig å gi dem fysisk forbindelse(gi flere sockets på hovedkortet), løse problemer med prosessoridentifikasjon (se senere i denne artikkelen, samt min forrige merknad), koordinering av minnetilganger og avbruddslevering (avbruddskontrolleren må kunne rute avbrudd til flere prosessorer) og selvfølgelig støtte fra operativsystemet. Dessverre kunne jeg ikke finne en dokumentarisk omtale av opprettelsen av det første multiprosessorsystemet på Intel-prosessorer, men Wikipedia hevder at Sequent Computer Systems leverte dem allerede i 1987, ved bruk av Intel 80386-prosessorer. Støtte for flere brikker i ett system er i ferd med å bli utbredt , starter med Intel® Pentium.

Hvis det er flere prosessorer, har hver av dem sin egen kontakt på brettet. Hver av dem har komplette uavhengige kopier av alle ressurser, for eksempel registre, utførelsesenheter, cacher. De deler delt minne- RAM. Minne kan kobles til dem på forskjellige og ganske ikke-trivielle måter, men dette er en egen historie utenfor rammen av denne artikkelen. Det viktige er at i alle fall bør illusjonen av homogent delt minne tilgjengelig fra alle prosessorer som er inkludert i systemet opprettes for kjørbare programmer.

Klar for takeoff! Intel® Desktop Board D5400XS

Kjerne

Historisk sett dukket multikjerner i Intel IA-32 opp senere enn Intel® HyperThreading, men i det logiske hierarkiet kommer det neste.

Det ser ut til at hvis et system har flere prosessorer, er ytelsen høyere (på oppgaver som kan bruke alle ressurser). Imidlertid, hvis kostnadene for kommunikasjon mellom dem er for høye, blir alle gevinstene fra parallellitet drept av lange forsinkelser for overføring av vanlige data. Det er nettopp dette som observeres i multiprosessorsystemer - både fysisk og logisk er de veldig langt fra hverandre. Til effektiv kommunikasjon Under slike forhold er det nødvendig å komme opp med spesialiserte busser, for eksempel Intel® QuickPath Interconnect. Energiforbruk, størrelse og pris på den endelige løsningen reduseres selvsagt ikke av alt dette. Høy integrasjon av komponenter bør komme til unnsetning - kretser som utfører deler av et parallelt program må bringes nærmere hverandre, helst på én brikke. Med andre ord bør én prosessor organisere flere kjerner, identiske med hverandre i alt, men jobber selvstendig.

De første flerkjernede IA-32-prosessorene fra Intel ble introdusert i 2005. Siden den gang har det gjennomsnittlige antallet kjerner i server-, desktop- og nå mobile plattformer vokst jevnt og trutt.

I motsetning til to enkeltkjerneprosessorer på samme system som kun deler minne, kan to kjerner også dele cacher og andre minnerelaterte ressurser. Oftest forblir cachene på første nivå private (hver kjerne har sin egen), mens andre og tredje nivå kan enten deles eller separate. Denne systemorganisasjonen lar deg redusere dataleveringsforsinkelser mellom nabokjerner, spesielt hvis de jobber med en felles oppgave.

Mikrofotografi av en quad-core Intel prosessor kodenavnet Nehalem. Separate kjerner, en felles cache på tredje nivå, samt QPI-koblinger til andre prosessorer og en felles minnekontroller er tildelt.

Hypertråd

Fram til ca. 2002 var den eneste måten å få et IA-32-system i stand til å kjøre to eller flere programmer parallelt å bruke multiprosessorsystemer. Intel® Pentium® 4 samt Xeon-linjen med kodenavnet Foster (Netburst) introdusert ny teknologi- hypertråder eller hypertråder, - Intel® HyperThreading (heretter kalt HT).

Det er ikke noe nytt under solen. HT er spesielt tilfelle det som i litteraturen kalles simultaneous multithreading (SMT). I motsetning til "ekte" kjerner, som er komplette og uavhengige kopier, i tilfelle av HT, er bare deler av de interne nodene, primært ansvarlige for å lagre den arkitektoniske tilstanden - registre, duplisert i en prosessor. De eksekutive nodene som er ansvarlige for organisering og behandling av data forblir singular, og brukes til enhver tid av høyst en av trådene. I likhet med kjerner deler hypertråder cacher, men fra hvilket nivå avhenger av det spesifikke systemet.

Jeg vil ikke prøve å forklare alle fordeler og ulemper med SMT-design generelt og HT-design spesielt. Den interesserte leser kan finne en ganske detaljert diskusjon om teknologien i mange kilder, og selvfølgelig på Wikipedia. Jeg vil imidlertid merke meg følgende viktig poeng, som forklarer gjeldende grenser for antall hypertråder i produksjon i den virkelige verden.

Trådbegrensninger

I hvilke tilfeller er tilstedeværelsen av "urettferdige" multikjerner i form av HT berettiget? Hvis en applikasjonstråd ikke er i stand til å laste alle utførelsesnodene inne i kjernen, kan de "lånes ut" til en annen tråd. Dette er typisk for applikasjoner som har " flaskehals” ikke i beregninger, men i datatilgang, det vil si ofte generere cache-misser og måtte vente på at data skal leveres fra minnet. I løpet av denne tiden vil kjernen uten HT bli tvunget til tomgang. Tilstedeværelsen av HT lar deg raskt bytte frie utførende noder til en annen arkitektonisk tilstand (siden den er duplisert) og utføre instruksjonene. Dette er et spesielt tilfelle av en teknikk som kalles latency hiding, når en lang operasjon, hvorunder nyttige ressurser inaktiv, maskert av parallell utførelse av andre oppgaver. Hvis applikasjonen allerede har høy grad utnyttelse av kjerneressurser, vil tilstedeværelsen av hypertråder ikke tillate akselerasjon - "ærlige" kjerner er nødvendig her.

Typiske scenarier for skrivebord og serverapplikasjoner, designet for maskinarkitekturer generelt formål, har potensialet for parallellisme aktivert av HT. Dette potensialet blir imidlertid raskt brukt opp. Kanskje av denne grunn, på nesten alle IA-32-prosessorer overstiger ikke antall maskinvarehypertråder to. I typiske scenarier vil gevinsten ved å bruke tre eller flere hypertråder være liten, men tapet i formstørrelse, strømforbruk og kostnad er betydelig.

En annen situasjon observeres i typiske oppgaver som utføres på videoakseleratorer. Derfor er disse arkitekturene preget av bruk av SMT-teknologi med et større antall tråder. Siden Intel® Xeon Phi-koprosessorer (introdusert i 2010) er ideologisk og genealogisk ganske nær skjermkort, kan de ha fire hyperthreading på hver kjerne - en konfigurasjon som er unik for IA-32.

Logisk prosessor

Av de tre beskrevne "nivåene" av parallellitet (prosessorer, kjerner, hypertråder), kan noen eller til og med alle mangle i et bestemt system. Dette påvirkes BIOS-innstillinger(multi-core og multithreading er deaktivert uavhengig), mikroarkitekturfunksjoner (for eksempel var HT fraværende fra Intel® Core™ Duo, men ble returnert med utgivelsen av Nehalem) og systemhendelser (multi-prosessorservere kan slå av mislykkede prosessorer hvis feil oppdages og fortsetter å "fly" på de resterende). Hvordan er denne multi-level zoo av samtidighet synlig for operativsystemet og, til syvende og sist, for applikasjonsapplikasjoner?

Videre, for enkelhets skyld, angir vi antall prosessorer, kjerner og tråder i et bestemt system med tre ( x, y, z), Hvor x er antall prosessorer, y- antall kjerner i hver prosessor, og z- antall hypertråder i hver kjerne. Fra nå av vil jeg kalle dette tre topologi– et etablert begrep som har lite å gjøre med grenen av matematikk. Arbeid s = xyz definerer antall enheter som kalles logiske prosessorer systemer. Den definerer det totale antallet uavhengige kontekster av applikasjonsprosesser på et delt minnesystem, som kjøres parallelt, som operativsystemet er tvunget til å ta hensyn til. Jeg sier "tvungen" fordi den ikke kan kontrollere utførelsesrekkefølgen til to prosesser på forskjellige logiske prosessorer. Dette gjelder også for hypertråder: selv om de kjører "sekvensielt" på samme kjerne, er den spesifikke rekkefølgen diktert av maskinvaren og kan ikke observeres eller kontrolleres av programmer.

Oftest skjuler operativsystemet for sluttapplikasjoner funksjonene til den fysiske topologien til systemet det kjører på. For eksempel, følgende tre topologier: (2, 1, 1), (1, 2, 1) og (1, 1, 2) - OS vil representere to logiske prosessorer, selv om den første av dem har to prosessorer, andre - to kjerner, og den tredje - bare to tråder.

Windows Task Manager viser 8 logiske prosessorer; men hvor mye er det i prosessorer, kjerner og hypertråder?

Linux toppen viser 4 logiske prosessorer.

Dette er ganske praktisk for applikasjonsskapere - de trenger ikke å forholde seg til maskinvarefunksjoner som ofte er uviktige for dem.

Programvaredefinisjon av topologi

Å abstrahere topologien til et enkelt antall logiske prosessorer i noen tilfeller skaper selvfølgelig nok grunnlag for forvirring og misforståelser (i opphetede internettvister). Databehandlingsapplikasjoner som ønsker å presse maksimal ytelse ut av maskinvaren krever detaljert kontroll over hvor trådene deres skal plasseres: nærmere hverandre på tilstøtende hypertråder eller omvendt, lenger unna på forskjellige prosessorer. Hastigheten på kommunikasjon mellom logiske prosessorer innenfor samme kjerne eller prosessor er mye høyere enn hastigheten på dataoverføring mellom prosessorer. Mulighet for heterogenitet i organisasjonen tilfeldig tilgangsminne kompliserer også bildet.

Informasjon om topologien til systemet som helhet, samt posisjonen til hver logiske prosessor i IA-32, er tilgjengelig ved å bruke CPUID-instruksjonen. Siden ankomsten av de første multiprosessorsystemene, har det logiske blitt utvidet flere ganger. Til dags dato er dens deler inneholdt i ark 1, 4 og 11 av CPUID. Hvilket ark du skal se på kan bestemmes fra følgende flytskjema hentet fra artikkelen:

Jeg vil ikke kjede deg her med alle detaljene i de enkelte delene av denne algoritmen. Hvis det er interesse, kan neste del av denne artikkelen vies til dette. Jeg vil henvise den interesserte leser til, som undersøker denne problemstillingen så detaljert som mulig. Her vil jeg først kort beskrive hva APIC er og hvordan det forholder seg til topologi. Deretter skal vi se på å jobbe med ark 0xB (elleve in desimal), som er på for tiden er det siste ordet i "apico-building".

APIC-ID

Local APIC (advanced programmeable interrupt controller) er en enhet (nå en del av prosessoren) som er ansvarlig for å håndtere avbrudd som kommer til en spesifikk logisk prosessor. Hver logisk prosessor har sin egen APIC. Og hver av dem i systemet må ha unik verdi APIC-ID. Dette nummeret brukes av avbruddskontrollere for adressering ved levering av meldinger, og av alle andre (for eksempel operativsystemet) for å identifisere logiske prosessorer. Spesifikasjonen for denne avbruddskontrolleren har utviklet seg fra Intel 8259 PIC gjennom Dual PIC, APIC og xAPIC til x2APIC.

For øyeblikket har bredden på nummeret som er lagret i APIC-IDen nådd hele 32 biter, selv om det tidligere var begrenset til 16, og enda tidligere - bare 8 biter. I dag er rester fra gamle dager spredt utover CPUID, men CPUID.0xB.EDX returnerer alle 32 biter av APIC ID. På hver logisk prosessor som uavhengig utfører CPUID-instruksjonen, vil en annen verdi bli returnert.

Avklaring av familiebånd

APIC ID-verdien i seg selv forteller deg ikke noe om topologien. For å finne ut hvilke to logiske prosessorer som er plassert inne i én fysisk prosessor (dvs. de er "brødre" hypertråder), hvilke to som er inne i samme prosessor, og hvilke som er helt forskjellige prosessorer, må du sammenligne APIC ID-verdiene deres. Avhengig av graden av forhold, vil noen av bitene deres falle sammen. Denne informasjonen finnes i CPUID.0xB-underlister, som er operandkodet i ECX. Hver av dem beskriver posisjonen til bitfeltet til et av topologinivåene i EAX (mer presist, antall biter som må flyttes til høyre i APIC ID for å fjerne de lavere topologinivåene), samt type av dette nivået - hypertråd, kjerne eller prosessor - i ECX.

Logiske prosessorer plassert inne i samme kjerne vil ha de samme alle APIC ID-biter, bortsett fra de som tilhører SMT-feltet. For logiske prosessorer plassert i samme prosessor, alle biter unntatt Core- og SMT-feltene. Siden antallet underark for CPUID.0xB kan øke, denne ordningen vil tillate oss å støtte beskrivelsen av topologier med et større antall nivåer, hvis behovet oppstår i fremtiden. Dessuten vil det være mulig å innføre mellomnivåer mellom eksisterende.

En viktig konsekvens av organiseringen av denne ordningen er at det kan være "hull" i settet med alle APIC-IDer til alle logiske prosessorer i systemet, dvs. de vil ikke gå sekvensielt. For eksempel i flerkjerne prosessor med HT slått av, kan alle APIC-ID-er vise seg å være jevne, siden den minst signifikante biten, som er ansvarlig for koding av hypertrådnummeret, alltid vil være null.

Jeg legger merke til at CPUID.0xB ikke er den eneste informasjonskilden om logiske prosessorer som er tilgjengelig for operativsystemet. En liste over alle tilgjengelige prosessorer, sammen med deres APIC ID-verdier, er kodet i MADT ACPI-tabellen.

Operativsystemer og topologi

Operativsystemer gir informasjon om topologien til logiske prosessorer til applikasjoner som bruker deres egne grensesnitt.

På Linux finnes topologiinformasjon i /proc/cpuinfo-pseudofilen så vel som utdataene fra dmidecode-kommandoen. I eksemplet nedenfor filtrerer jeg innholdet av cpuinfo på et quad-core system uten HT, og etterlater bare oppføringer relatert til topologien:

Skjult tekst

ggg@shadowbox:~$ cat /proc/cpuinfo |grep "prosessor\|fysisk\ id\|søsken\|kjerne\|kjerner\|apicid" prosessor: 0 fysisk id: 0 søsken: 4 kjerne-id: 0 cpu-kjerner: 2 apicid: 0 initial apicid: 0 prosessor: 1 fysisk id: 0 søsken: 4 core id: 0 cpu kjerner: 2 apicid: 1 initial apicid: 1 prosessor: 2 fysisk id: 0 søsken: 4 core id: 1 cpu kjerner: 2 apicid: 2 initial apicid: 2 prosessor: 3 fysisk id: 0 søsken: 4 core id: 1 cpu-kjerner: 2 apicid: 3 initial apicid: 3

På FreeBSD rapporteres topologien via sysctl-mekanismen i kern.sched.topology_spec-variabelen som XML:

Skjult tekst

bruker@vert:~$ sysctl kern.sched.topology_spec kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3, 4, 5, 6, 7 0, 1 TRÅD gruppeSMT gruppe 2, 3 TRÅD gruppeSMT gruppe 4, 5 TRÅD gruppeSMT gruppe 6, 7 TRÅD gruppeSMT gruppe

I MS Windows 8 kan topologiinformasjon sees i Task Manager.

Prosess(eller oppgave) er en abstraksjon som beskriver et kjørende program.

For OS prosess representerer en arbeidsenhet, en forespørsel om forbruk av systemressurser. Prosessstyringsdelsystemet planlegger utførelse av prosesser, dvs. fordeler prosessortid mellom flere samtidig eksisterende prosesser i systemet, og tar seg også av oppretting og destruksjon av prosesser, gir prosesser nødvendig systemressurser, støtter kommunikasjon mellom prosesser.

Noen av ressursene blir allokert til en prosess når den opprettes, og noen tildeles dynamisk basert på forespørsler under kjøring. Ressurser kan tildeles en prosess for hele livet eller bare for en viss periode. Når du utfører disse funksjonene, samhandler promed andre OS-undersystemer som er ansvarlige for ressursstyring, slik som minnestyringsundersystemet, input/output-undersystemet og filsystemet. Når et system kjører flere uavhengige oppgaver samtidig, oppstår det ytterligere problemer. Selv om prosesser oppstår og kjøres asynkront, kan det hende de må samhandle, for eksempel ved utveksling av data. Matching av prosesshastigheter er også svært viktig for å forhindre raseforhold der flere prosesser prøver å endre den samme filen, vranglåser eller andre kollisjoner som oppstår når ressurser deles. Prosesssynkronisering er en av de viktige funksjoner undersystemer for prosesskontroll.

Hver gang en prosess avsluttes, lukker proalle filene som prosessen jobbet med, og frigjør områder med RAM som er tildelt for koder, data og systeminformasjonsstrukturer i prosessen. Alle mulige OS-køer og ressurslister som inneholder referanser til prosessen som avsluttes blir korrigert.

For å støtte multiprogrammering må operativsystemet definere og designe for seg selv de interne arbeidsenhetene som prosessoren og andre datamaskinressurser skal deles mellom. Det må man huske på multiprogrammering er en måte å organisere på databehandlingsprosess, der datamaskinens minne inneholder flere programmer som vekselvis kjøres på én prosessor.

For tiden definerer de fleste operativsystemer to typer arbeidsenheter. En større arbeidsenhet, vanligvis kalt en prosess eller oppgave, krever at flere mindre arbeider fullføres, referert til som en tråd eller tråd.

Selvfølgelig, noe arbeid datasystem består i å kjøre et eller annet program. Derfor er både prosessen og tråden knyttet til en bestemt programkode, som for disse formålene er utformet som en kjørbar modul. For at denne programkoden skal kjøres, må den lastes inn i RAM, kanskje noe diskplass tildelt for datalagring, tilgang til input/output-enheter, f.eks. seriell port. Under kjøring kan programmet også trenge tilgang til HI, for eksempel filer. Og selvfølgelig er det umulig å kjøre et program uten å gi det CPU-tid, dvs. tiden hvor prosessoren utfører kodene til et gitt program.

I systemer der både prosesser og tråder eksisterer, anses prosessen av OS som en forespørsel om å forbruke alle typer ressurser, bortsett fra én prosessortid. Denne siste viktigste ressurs distribuert av operativsystemet mellom andre arbeidsenheter - tråder, som fikk navnet sitt på grunn av at de representerer sekvenser (utførelsestråder) av kommandoer.

I det enkleste tilfellet består en prosess av en enkelt tråd, og slik ble begrepet «prosess» tolket frem til midten av 1980-tallet, og i samme form er det bevart i noen moderne operativsystemer. I systemer av denne typen er konseptet "flyt" fullstendig absorbert av konseptet "prosess", dvs. Det gjenstår bare én enhet med arbeid og ressursforbruk - prosessen. Multiprogrammering utføres i slike operativsystemer på prosessnivå.

Det er tre grunnleggende tilstander for en prosess: klar, kjører og blokkert.

På et enkeltprosessorsystem kan bare én prosess kjøres. Samtidig kan det være flere klare og blokkerte prosesser som venter på at noen hendelser (for eksempel I/O) skal inntreffe. I dette tilfellet er listen over klare prosesser sortert etter prioritet.

For å forhindre at prosesser forstyrrer distribusjonen av ressurser, samt skader hverandres koder og data, må operativsystemet løse den viktigste oppgaven - å isolere en prosess fra en annen.

For å gjøre dette gir OS hver prosess et eget virtuelt adresserom, slik at ingen prosess kan motta direkte adgang til kommandoer og data fra en annen prosess.

Behandle virtuelt adresserom er en samling adresser som kan manipuleres programvaremodul prosess.

Operativsystemet kartlegger en prosess virtuelle adresserom til prosessens tildelte fysiske minne.

Når interaksjon er nødvendig, henvender prosessene seg til operativsystemet, som, som en mellommann, gir dem midler for interprosesskommunikasjon - rørledninger, postkasser, delte minneseksjoner og noen andre.

Men i systemer som mangler begrepet flyt, oppstår det problemer med å organisere parallell databehandling i prosessen. Og et slikt behov kan oppstå. Faktisk, med multiprogrammering øker det gjennomstrømning system, men en separat prosess kan aldri utføres raskere enn i enkeltprogrammodus (enhver deling av ressurser bremser bare arbeidet til en av deltakerne på grunn av ekstra tid brukt på å vente på at ressursen blir tilgjengelig). Imidlertid kan en applikasjon som kjører innenfor en enkelt prosess ha intern parallellitet, noe som i prinsippet kan tillate at løsningen blir raskere. Hvis programmet for eksempel gir tilgang til ekstern enhet, så under denne operasjonen kan du ikke blokkere utførelsen av hele prosessen, men fortsette beregningene i en annen gren av programmet. Å kjøre flere jobber parallelt i en enkelt interaktiv applikasjon forbedrer brukereffektiviteten. Når du arbeider med et tekstredigeringsprogram, er det derfor ønskelig å kunne kombinere skriving av ny tekst med tidkrevende operasjoner som å formatere en betydelig del av teksten på nytt, skrive ut et dokument eller lagre det på en lokal eller ekstern disk.

Tråder oppsto i OS som et middel til å parallellisere beregninger. Selvfølgelig kan problemet med å parallellisere beregninger innenfor en applikasjon løses ved hjelp av tradisjonelle metoder.

For det første kan applikasjonsprogrammereren ta ansvar vanskelig oppgave organisering av parallellisme ved å velge en bestemt dispatcher-subrutine i applikasjonen, som med jevne mellomrom overfører kontroll til en eller annen gren av beregninger. I dette tilfellet viser programmet seg å være logisk veldig forvirrende, med mange overføringer av kontroll, noe som betydelig kompliserer feilsøking og modifikasjon.

For det andre er løsningen å lage for én applikasjon flere prosesser for hver av parallelle arbeider. Men bruker den til å lage prosesser standard betyr OS tillater oss ikke å ta hensyn til det faktum at disse prosessene løser et enkelt problem, noe som betyr at de har mye til felles med hverandre - de kan jobbe med de samme dataene, bruke samme kodesegment og være utstyrt med samme tilgangsrettigheter til ressurser datasystem.

I operativsystemet, sammen med prosesser, er det nødvendig med en annen mekanisme for parallellisering av beregninger, som vil ta hensyn til de nære forbindelsene mellom individuelle beregningsgrener av samme applikasjon.

For disse formålene tilbyr moderne operativsystemer en multithreading-mekanisme. Samtidig innføres en ny arbeidsenhet - tråd for utførelse og begrepet "prosess" endrer betydning i stor grad. Konseptet "tråd" tilsvarer den sekvensielle overgangen til prosessoren fra en programinstruksjon til en annen. Operativsystemet fordeler prosessortid mellom tråder. OS tildeler et adresseområde og et sett med ressurser til en prosess som deles mellom alle dens tråder.

I enkeltprogramsystemer er det ikke nødvendig å introdusere et konsept som betegner en arbeidsenhet, siden det ikke er noe problem med ressursdeling.

Å lage tråder krever mindre overhead fra OS enn prosesser. I motsetning til prosesser som tilhører forskjellige konkurrerende applikasjoner, tilhører alle tråder i én prosess alltid samme applikasjon, så OS isolerer tråder i mye mindre grad enn prosesser i et tradisjonelt flerprogramsystem. Alle tråder av samme prosess bruker delte filer, tidtakere, enheter, samme område med RAM, samme adresseområde. Dette betyr at de deler de samme globale variablene. Siden hver tråd kan få tilgang til en hvilken som helst virtuell adresse til en prosess, kan en tråd bruke en annen tråds stabel. Det er ingen enkelt prosess mellom trådene full beskyttelse, fordi det for det første er umulig, og for det andre er det ikke nødvendig. For å organisere interaksjon og datautveksling trenger ikke tråder å få tilgang til operativsystemet i det hele tatt; de trenger bare å bruke delt minne - en tråd skriver data, og den andre leser den. På den annen side, flyter ulike prosesser er fortsatt godt beskyttet mot hverandre.

Multiprogrammering er mer effektivt på trådnivå i stedet for på prosessnivå. Hver tråd har egen skranke kommandoer og stabel. En oppgave utformet som flere tråder i én prosess kan fullføres raskere på grunn av pseudo-parallell (eller parallell i et multiprosessorsystem) utførelse av dens individuelle deler. Multithreading kan brukes spesielt effektivt for å kjøre distribuerte applikasjoner; for eksempel kan en multithreaded server utføre forespørsler fra flere klienter parallelt.

Bruken av tråder er ikke bare assosiert med ønsket om å øke systemytelsen gjennom parallell databehandling, men også med målet om å lage mer lesbare, logiske programmer. Innføringen av flere utførelsestråder forenkler programmering. For eksempel, i forfatter-leseroppgaver, skriver en tråd til en buffer og en annen leser fra den. Siden de deler en felles buffer, bør de ikke gjøres til separate prosesser. Et annet eksempel på bruk av tråder er å kontrollere signaler som tastaturavbrudd (Del eller Break). I stedet for å håndtere avbruddssignalet, er en tråd tildelt til konstant å vente på at signaler kommer. Dermed kan bruk av tråder redusere behovet for avbrudd på brukernivå. I disse eksemplene er ikke parallell utførelse like viktig som programklarhet.

Den største effekten av introduksjonen av flertrådsbehandling oppnås i multiprosessorsystemer, der tråder, inkludert de som tilhører samme prosess, kan kjøres på forskjellige prosessorer virkelig parallelt (og ikke pseudo-parallelle).

Lag prosess Først av alt betyr det å lage en prosessbeskrivelse, som er en eller flere informasjonsstrukturer som inneholder all informasjon om prosessen som er nødvendig for at OS skal administrere den. Slik informasjon kan for eksempel inkludere en prosessidentifikator, informasjon om minneplasseringen til den kjørbare modulen, graden av privilegium for prosessen (prioritet og tilgangsrettigheter), etc.

Eksempler på prosessbeskrivelser er Task Control Block (TCB) i OS/360, Process Control Block (PCB) i OS/2, prosesshåndtaket i UNIX, objektprosessen i Windows NT.

Opprettelsen av en prosessbeskrivelse markerer fremveksten av en annen utfordrer for dataressurser i systemet. Fra dette tidspunktet må operativsystemet ta hensyn til behovene til den nye prosessen ved tildeling av ressurser.

Å lage en prosess innebærer å laste inn kodene og dataene til det kjørbare programmet denne prosessen fra disk til RAM. For å gjøre dette, må operativsystemet oppdage plasseringen av et slikt program på disken, omfordele RAM og allokere minne til det kjørbare programmet til den nye prosessen. Deretter er det nødvendig å lese programmet inn i minneområdene som er tildelt det, og eventuelt endre programparametrene avhengig av plasseringen i minnet.

På systemer med virtuell hukommelse i det første øyeblikket kan bare deler av kodene og dataene til prosessen lastes inn for å "pumpe opp" resten etter behov. Det er systemer der det i prosessopprettingsstadiet ikke nødvendigvis er nødvendig å laste koder og data inn i RAM; i stedet blir den kjørbare modulen kopiert fra den katalogen filsystem, der den opprinnelig var plassert, inn i bytteområdet - et spesielt område på disken reservert for lagring av prosesskoder og data. Ved å utføre alle disse handlingene, samhandler protett med minnestyringsundersystemet og filsystemet.

I et flertrådet system, når en prosess opprettes, oppretter operativsystemet minst én utførelsestråd for hver prosess. Når du oppretter en tråd, akkurat som når du oppretter en prosess, genererer operativsystemet en spesiell informasjonsstruktur - en trådbeskrivelse, som inneholder trådidentifikatoren, tilgangsrettigheter og prioritetsdata, trådtilstand og annen informasjon. I original tilstand en tråd (eller prosess, hvis vi snakker om et system der konseptet "tråd" ikke er definert) er i suspendert tilstand. Øyeblikket for å velge en tråd for utførelse utføres i samsvar med regelen for å gi prosessortid akseptert i dette systemet og tar hensyn til alle eksisterende tråder og prosesser. Hvis prosesskodene og dataene er i bytteområdet, en nødvendig betingelse Aktivering av en prosesstråd er også tilgjengeligheten av plass i RAM for å laste den kjørbare modulen.

På mange systemer kan en tråd be OS om å lage såkalte etterkommerstrømmer. Ulike operativsystemer strukturerer forholdet mellom barnetråder og deres foreldre forskjellig. For eksempel, i noen operativsystemer, er kjøringen av en overordnet tråd synkronisert med dens etterkommere; spesielt, etter fullføringen av den overordnede tråden, kan operativsystemet slutte å kjøre alle dens etterkommere. På andre systemer kan underordnede tråder kjøres asynkront i forhold til overordnet tråd. Etterkommere arver vanligvis mange av egenskapene til foreldrestrømmene deres. I mange systemer er gyting av barn den primære mekanismen for å lage prosesser og tråder.

Prosessplanlegging inkluderer løsning av følgende oppgaver:

■ fastsettelse av tidspunktet for endring av prosessen som utføres;

■ velge en prosess som skal utføres fra en kø med klare prosesser;

■ bytte konteksten til de "gamle" og "nye" prosessene.

De to første problemene er løst programvare, og sistnevnte er i stor grad maskinvarebasert.

Det er mange forskjellige prosessplanleggingsalgoritmer som løser de oppførte problemene på forskjellige måter, forfølger forskjellige mål og gir ulik kvalitet på multiprogrammering. Blant dette settet med algoritmer, la oss se nærmere på to grupper av de vanligste algoritmene: kvantiseringsbaserte algoritmer og prioritetsbaserte algoritmer.

I samsvar med algoritmer basert på kvantisering, en endring av aktiv prosess skjer hvis:

■ prosessen avsluttet og forlot systemet;

■ det oppstod en feil;

■ prosessen har gått inn i "venter"-tilstand;

■ prosessortidsdelen som er tildelt denne prosessen, er oppbrukt.

En prosess som har uttømt sitt kvantum, plasseres i "klar"-tilstand og venter på at et nytt kvantum av prosessortid blir gitt til den, og velges for utførelse i henhold til en viss regel. ny prosess fra klarkøen. På denne måten opptar ingen prosess CPU-en lenge, og det er grunnen til at kvantisering er mye brukt i tidsdelingssystemer.

Kvanter allokert til prosesser kan være den samme for alle prosesser eller forskjellige. Kvanter som er allokert til én prosess kan ha en fast verdi eller variere i ulike perioder av prosessens levetid. Prosesser som ikke fullt ut har brukt kvantumet som er allokert til dem (for eksempel på grunn av I/O-aktivitet) kan eller kan ikke motta kompensasjon i form av privilegier under påfølgende vedlikehold. Køen av klare prosesser kan organiseres på forskjellige måter: syklisk, i henhold til regelen "først inn, først ut" (FIFO) eller i henhold til regelen "sist inn, først ut" (LIFO).

I prioritetsbaserte algoritmer konseptet "prioritering" av prosessen brukes.

En prioritet– dette er et tall som karakteriserer graden av privilegium i prosessen ved bruk av ressurser datamaskin, spesielt CPU-tid: jo høyere prioritet, jo høyere privilegier.

Prioriteten kan uttrykkes som heltall eller brøk, positive eller negative verdier. Jo høyere privilegier en prosess har, jo mindre tid vil den bruke i køer. Prioriteten kan tildeles direkte av systemadministratoren avhengig av viktigheten av arbeidet eller gebyret som betales, eller beregnes av OS selv i henhold til visse regler; den kan forbli fast gjennom hele prosessens levetid eller endres over tid iht. noen lov. I sistnevnte tilfelle kalles prioriteringene dynamisk.

Det finnes to typer prioritetsalgoritmer: Algoritmer som bruker relative prioriteter og algoritmer som bruker absolutte prioriteter.

I begge tilfeller utføres valget av en prosess for utførelse fra klarkøen på samme måte: prosessen med høyest prioritet velges. Problemet med å bestemme tidspunktet for endring av den aktive prosessen løses på forskjellige måter. I systemer relative prioriteringer Den aktive prosessen kjører til den forlater selve prosessoren, går inn i "blokkerende" tilstand (eller det oppstår en feil, eller prosessen avsluttes). På systemer med absolutte prioriteringer utførelse av den aktive prosessen avbrytes under en annen betingelse: hvis en prosess vises i køen av klare prosesser hvis prioritet er høyere enn prioriteten til den aktive prosessen. I dette tilfellet går den avbrutte prosessen inn i klar tilstand.

I mange operativsystemer bygges planleggingsalgoritmer ved å bruke både kvantisering og prioriteringer. For eksempel er planlegging basert på kvantisering, men kvanteverdien og (eller) rekkefølgen som en prosess velges i fra en kø av klare bestemmes av prioriteringene til prosessene.

Det er to hovedtyper av prosessplanleggingsprosedyrer: forebyggende og ikke-forebyggende.

Ikke-forebyggende multitasking(Non-preemptive multitasking) er en metode for å planlegge prosesser der den aktive prosessen kjører til den på eget initiativ gir kontroll til OS-planleggeren slik at den velger en annen prosess klar til å kjøre fra køen.

Forebyggende multitasking(Preemptive multitasking) er en metode der beslutningen om å bytte prosessoren fra å utføre en prosess til å utføre en annen tas av OS-planleggeren, og ikke av selve den aktive oppgaven.

Begrepene «preemptive» og «non-preemptive» identifiseres noen ganger med begrepene prioriterte og ikke-prioriterte disipliner, som er helt feil, samt med begrepene absolutte og relative prioriteringer, som delvis er feil. Forebyggende og ikke-forebyggende multitasking er bredere begreper enn prioriterte typer. Oppgaveprioriteringer kan eller kan ikke brukes i både forebyggende og ikke-forebyggende planleggingsmetoder. Ved bruk av prioriteringer kan således disiplinen med relative prioriteringer klassifiseres som en klasse av systemer med ikke-forebyggende multitasking, og disiplinen med absolutte prioriteringer kan klassifiseres som en klasse av systemer med forebyggende multitasking. Den ikke-prioriterte planleggingsdisiplinen, basert på tildeling av like tidsdeler for alle oppgaver, refererer til forebyggende algoritmer.

Hovedforskjellen mellom forebyggende og ikke-forebyggende multitasking er graden av sentralisering av oppgaveplanleggingsmekanismen. På forebyggende multitasking oppgaveplanleggingsmekanismen er helt konsentrert i operativsystemet og programmereren skriver søknaden sin uten å bekymre seg for at den vil bli utført parallelt med andre oppgaver. I dette tilfellet utfører operativsystemet følgende funksjoner: bestemmer øyeblikket når en aktiv oppgave fjernes fra utførelse, husker konteksten, velger den neste fra køen med klare oppgaver og starter den for utførelse, laster konteksten. På ikke-forebyggende multitasking Planleggingsmekanismen er fordelt mellom systemet og applikasjonsprogrammene. Søknadsprogram, etter å ha mottatt kontroll fra operativsystemet, bestemmer det selv tidspunktet for fullføring av neste iterasjon og overfører kontrollen til operativsystemet ved å bruke noen systemanrop, og operativsystemet danner køer med oppgaver og velger neste oppgave for utførelse i samsvar med en eller annen algoritme ( for eksempel ved å ta hensyn til prioriteringer). Denne mekanismen skaper problemer for både brukere og utviklere.

For brukere betyr dette at kontrollen over systemet går tapt i en vilkårlig tidsperiode, som bestemmes av applikasjonen (ikke brukeren). Hvis en applikasjon bruker for mye tid på noe arbeid, som å formatere en disk, kan ikke brukeren bytte fra den oppgaven til en annen oppgave, som f.eks. tekstredigerer, mens formateringen fortsetter i bakgrunnen. Denne situasjonen er uønsket fordi brukere vanligvis ikke vil vente lenge på at maskinen skal fullføre oppgaven. Derfor må applikasjonsutviklere for et forebyggende driftsmiljø, som påtar seg rollen som planlegger, designe applikasjoner slik at de utfører oppgavene sine i små deler. For eksempel kan et formateringsprogram formatere ett spor på en diskett og returnere kontrollen til systemet. Etter å ha fullført andre oppgaver, vil systemet returnere kontrollen til formateringen for å formatere neste spor. Denne metoden for å dele tid mellom oppgaver fungerer, men den kompliserer utviklingen av programmer betydelig og stiller økte krav til programmererens kvalifikasjoner. Programmereren må sørge for at programmet hans er "vennlig" til andre programmer som kjører samtidig med det, og gir dem kontroll ganske ofte. En ekstrem manifestasjon av en applikasjons "uvennlighet" er at den fryser, noe som fører til en generell systemkrasj. I systemer med forebyggende multitasking er slike situasjoner vanligvis utelukket, siden den sentrale planleggingsmekanismen vil fjerne den fastlåste oppgaven fra utførelse.

Fordelingen av planleggerfunksjoner mellom systemet og applikasjonene er imidlertid ikke alltid en ulempe, og under visse forhold kan det også være en fordel, fordi det lar applikasjonsutvikleren designe den planleggingsalgoritmen som er best egnet for en gitt applikasjon. fast urskive oppgaver. Siden utvikleren selv bestemmer i programmet tidspunktet når kontrollen returneres, eliminerer dette irrasjonelle avbrudd av programmer på "ubeleilige" tidspunkter. I tillegg løses problemer enkelt deling data: oppgaven bruker den utelukkende under hver iterasjon og er sikker på at ingen andre vil endre disse dataene i denne perioden. En betydelig fordel med forskyvningssystemer er mer høy hastighet bytte fra oppgave til oppgave.

Eksempel effektiv bruk ikke-preemptive multitasking er NetWare-filserveren, som i stor grad takket være dette har oppnådd høy hastighet på filoperasjoner.

Imidlertid implementerer nesten alle moderne operativsystemer fokusert på applikasjonskjøring med høy ytelse (UNIX, Windows NT, OS/2, VAX/VMS) forebyggende multitasking. I I det siste Turen har kommet til OS-klassen av stasjonære systemer. Kanskje av denne grunn kalles forebyggende multitasking ofte ekte.

4.1 Prosesser

4.1.1 Prosesskonsept

Prosess(oppgave) - et program i utførelsesmodus.

Hver prosess er knyttet til sin adresseområde, som den kan lese fra og som den kan skrive data til.

Adresseområdet inneholder:

selve programmet

data for programmet

programstabel

Hver prosess har et sett knyttet til seg registrerer , For eksempel:

programteller (i prosessoren) - et register som inneholder adressen til neste kommando i køen for utførelse. Etter at en instruksjon er hentet fra minnet, justeres programtelleren og pekeren flyttes til neste instruksjon.

stabelpeker

På mange operativsystemer lagres all informasjon om hver prosess i tillegg til innholdet i dens eget adresseområde prosesstabell operativsystem.

Noen tabellfelt:

Prosessledelse	Minnehåndtering	Filbehandling
Registrerer Programteller Stabelpeker Prosesstilstand En prioritet Planleggingsmuligheter Prosess-ID Foreldreprosess Prosessgruppe Prosess starttid CPU-tid brukt	Peker til tekstsegment Peker til datasegment Peker til et stabelsegment	Rotkatalogen Arbeidskatalog Filbeskrivelser bruker-ID Gruppe-ID

4.1.2 Prosessmodell

I et multitasking-system bytter den virkelige prosessoren fra prosess til prosess, men for å forenkle modellen vurderer vi et sett med prosesser som kjører parallelt (pseudo-parallell).

Tenk på en krets med fire kjørende programmer.

Bare én prosess er aktiv om gangen

Til høyre er prosesser som kjører parallelt, hver med sin egen programteller. Selvfølgelig er det faktisk bare én fysisk programteller, som den aktuelle prosessens logiske programteller lastes inn. Når tiden som er allokert til den aktuelle prosessen slutter, lagres den fysiske programtelleren i minnet, i prosessens logiske programteller.

4.1.3 Opprette en prosess

Tre hovedhendelser som fører til opprettelsen av prosesser (call gaffel eller Opprett prosess):

En kjørende prosess sender et systemkall for å opprette en prosess

Brukerforespørsel om å opprette en prosess

I alle tilfeller sender den aktive gjeldende prosessen et systemkall for å opprette en ny prosess.

I UNIX er hver prosess tildelt en prosessidentifikator (PID - Process IDentifier)

4.1.4 Avslutte prosessen

Fire hendelser som får en prosess til å stoppe (ring exit eller ExitProcess):

Planlagt ferdigstillelse (slutt på utførelse)

Planlagt avslutning på en kjent feil (for eksempel manglende fil)

Avslutt på grunn av fatal feil (programfeil)

Ødelagt av en annen prosess

Dermed består en suspendert prosess av sitt eget adresseområde, vanligvis kalt måte å minne på(kjernebilde), og komponenter i prosesstabellen (inkludert dens registre).

4.1.5 Prosesshierarki

I UNIX-systemer Det er et strengt hierarki av prosesser. Hver ny prosess opprettet systemanrop gaffel er et barn av den forrige prosessen. Barneprosessen mottar variabler, registre osv. fra forelderen. Etter calling fork, når forelderens data er kopiert, påvirker ikke påfølgende endringer i en av prosessene den andre, men prosessene husker hvem forelderen er.

I dette tilfellet er det i UNIX også stamfaren til alle prosesser - prosessen i det.

Prosesstre for UNIX-systemer

4.1.6 Prosessstatus

Tre prosesstilstander:

Utførelse (CPU okkupert)

Klar (en prosess er midlertidig suspendert for å la en annen prosess kjøre)

Venter (prosessen kan ikke startes av interne årsaker, for eksempel å vente på en I/O-operasjon)

Mulige overganger mellom stater.

1. Prosessen er blokkert og venter på inndata

2. Planleggeren velger en annen prosess

3. Planleggeren velger denne prosessen

4. Inndata har kommet

Overganger 2 og 3 kalles opp av operativsystemets prosessplanlegger, så prosessene selv vet ikke engang om disse overgangene. Fra selve prosessenes synspunkt er det to tilstander av utførelse og venting.

På servere setter de ofte flere prosesser i standby-modus for å få raskere respons på en klientforespørsel, og så snart serveren mottar forespørselen går prosessen fra "venter" til "utfører". Denne overgangen er mye raskere enn å starte en ny prosess.

4.2 Tråder (tråder, lett prosess)

4.2.1 Begrepet flyt

Hver prosess har et adresseområde og et enkelt strømme kjørbare kommandoer. I flerbrukersystemer må en ny prosess opprettes for å betjene klienten hver gang den samme tjenesten åpnes. Dette er mindre fordelaktig enn å lage en kvasi-parallell tråd i den prosessen med et enkelt adresseområde.

4.2.2 Strømningsmodell

Hver tråd er assosiert med:

Teller for kommandoutførelse

Registrerer for aktuelle variabler

Stat

Tråder deler elementer av prosessen sin seg imellom:

Adresseplass

Globale variabler

Åpne filer

• Semaforer

  Statistisk informasjon.

Ellers er modellen identisk med prosessmodellen.

POSIX og Windows har støtte på kjernenivå for tråder.

4.2.3 Fordeler med å bruke tråder

Forenkling av programmet i noen tilfeller ved å bruke et felles adresseområde.

Hastigheten for å lage en strøm, sammenlignet med prosessen, er omtrent 100 ganger.

Forbedre ytelsen til selve programmet, fordi Det er mulig å utføre beregninger på prosessoren og en I/O-operasjon samtidig. Eksempel: Et tekstredigeringsprogram med tre tråder kan samhandle med brukeren samtidig, formatere tekst og skrive en sikkerhetskopi til disk.

4.2.4 Implementering av tråder i brukerrom, kjerne og blandet

B- tråder i kjerneplass

Når EN Kjernen vet ingenting om tråder. Hver prosess trenger flyttabell, lik prosesstabellen.

Fordeler med saken EN:

Slik multithreading kan implementeres på en kjerne som ikke støtter multithreading

Mer raskt bytte, opprettelse og avslutning av tråder

En prosess kan ha sin egen planleggingsalgoritme.

Ulemper ved saken EN:

Ingen timeravbrudd i én prosess

Når du bruker en blokkering (prosessen settes i standby-modus, for eksempel: lesing fra tastaturet, men ingen data mottas) systemforespørsel alle andre tråder er blokkert.

Implementeringskompleksitet