Multitasking ( engelsk multitasking ) er en egenskab ved operativsystemet eller runtime-miljøet for at give mulighed for parallel (eller pseudo -parallel ) behandling af flere opgaver . Ægte multitasking af operativsystemet er kun mulig i distribuerede computersystemer .
Der er 2 typer multitasking [1] :
Multithreading er en specialiseret form for multitasking [1] .
Primitive multitasking-miljøer giver ren "ressourcedeling", hvor hver opgave er tildelt et specifikt hukommelsesområde, og opgaven aktiveres med nøje definerede tidsintervaller.
Mere avancerede multitasking-systemer tildeler ressourcer dynamisk, når en opgave starter i hukommelsen eller forlader hukommelsen, afhængigt af dens prioritet og systemstrategien. Dette multitasking-miljø har følgende funktioner:
Den største vanskelighed ved at implementere et multitasking-miljø er dets pålidelighed, udtrykt i hukommelsesbeskyttelse, håndtering af fejl og afbrydelser , beskyttelse mod frysninger og deadlocks .
Ud over at være pålideligt skal et multitasking-miljø være effektivt. Omkostningerne ved ressourcer til at vedligeholde det bør ikke: forstyrre processer, bremse deres arbejde, begrænse hukommelsen skarpt.
I starten var implementeringen af multitasking-operativsystemer et alvorligt teknisk problem, hvorfor introduktionen af multitasking-systemer blev forsinket, og brugerne foretrak single-tasking-systemer i lang tid efter implementeringen.
Senere, efter fremkomsten af flere vellykkede løsninger, begyndte multitasking-miljøer at blive bedre og bruges nu overalt.
For første gang blev multitasking af operativsystemet implementeret under udviklingen af Multics -operativsystemet ( 1964 ). Et af de første multitasking-systemer var OS/360 (1966 [2] ), brugt til IBM-computere og deres sovjetiske modstykker ES EVM . Udviklingen af systemet blev stærkt forsinket, og for første gang fremlagde IBM en enkelt-opgave DOS for at tilfredsstille kunderne før den fulde idriftsættelse af OS / 360. Systemet er blevet kritiseret på grund af lav pålidelighed og vanskeligheder ved drift.
I 1969 blev UNIX -systemet på basis af Multics udviklet med en ret pæn algoritmisk løsning på problemet med multitasking. I øjeblikket er dusinvis af operativsystemer blevet skabt baseret på UNIX.
PDP-11- computere og deres sovjetiske SM-4- modstykker brugte RSX-11- multitasking-systemet (det sovjetiske modstykke er SM EVM RTOS ) og TSX-PLUS-tidsfordelingssystemet, som giver begrænsede multitasking-kapaciteter og en flerbrugertid delingstilstand, der emulerer for hver bruger en enkeltopgave RT-11 (sovjetisk analog - RAFOS ). Sidstnævnte løsning var meget populær på grund af den lave effektivitet og pålidelighed af et fuldgyldigt multitasking-system.
En pæn løsning viste sig at være VMS -operativsystemet , oprindeligt udviklet til VAX-computere (den sovjetiske ækvivalent er SM-1700 ) som en udvikling af RSX-11.
Verdens første multimedie - pc Amiga 1000 ( 1984 ) blev oprindeligt designet med fuld hardwareunderstøttelse til forebyggende multitasking i realtid i AmigaOS . I dette tilfælde blev udviklingen af hardware og software udført parallelt, hvilket førte til, at med hensyn til multitasking-planlægningskvantisering (1/50 sekund pr. kontekstswitch), forblev AmigaOS uovertruffen på personlige computere i lang tid .
Multitasking blev også leveret af Microsoft i Windows- operativsystemer . Brugen af VMS-erfaring gav systemer med væsentlig højere ydeevne og pålidelighed. Med hensyn til multitasking-kontekstskiftetid (kvantisering), er det kun disse operativsystemer, der kan sammenlignes med AmigaOS og UNIX (og også dets efterkommere, såsom Linux-kernen ).
Interessant nok kan multitasking implementeres ikke kun i driftsmiljøet, men også i sprogmiljøet. For eksempel kræver specifikationerne for programmeringssprogene Modula-2 og Ada understøttelse af multitasking uden for ethvert operativsystem. Som et resultat heraf gjorde JPI / Clarions populære implementering af programmeringssproget TopSpeed Modula-2 i første halvdel af 1990'erne det muligt at organisere forskellige typer multitasking (samarbejdsvillig og forebyggende - se nedenfor) for trådene i én program inden for et så fundamentalt enkelt-opgave operativsystem som MS-DOS . Dette blev gjort ved at inkludere en kompakt opgaveplanlægger i programmodulet , indeholdende en timer-afbrydelseshåndtering [3] . Programmeringssprog, der har denne egenskab, kaldes nogle gange realtidssprog [4] .
En type multitasking, hvor operativsystemet indlæser to eller flere applikationer i hukommelsen på samme tid, men kun hovedapplikationen får CPU-tid. For at et baggrundsprogram kan køre, skal det være aktiveret. Sådan multitasking kan implementeres ikke kun i operativsystemet, men også ved hjælp af task switcher-programmer. Kendt i denne kategori er DESQview- programmet , som kørte under DOS og blev først udgivet i 1985.
Fordele: du kan bruge allerede kørende programmer skrevet uden multitasking i tankerne.
Ulemper: umuligt i ikke-interaktive systemer, der fungerer uden menneskelig indgriben. Interaktion mellem programmer er yderst begrænset.
En type multitasking, hvor den næste opgave kun kører, efter at den aktuelle opgave eksplicit har erklæret sig klar til at give CPU-tid til andre opgaver. Som et særligt tilfælde er en sådan erklæring underforstået, når man forsøger at fange et allerede optaget mutex -objekt (Linux-kerne), såvel som når man venter på, at den næste besked ankommer fra brugergrænseflade-undersystemet (Windows-versioner op til 3.x inklusive, samt 16-bit applikationer i Windows 9x ).
Cooperative multitasking kan kaldes "second stage" multitasking, fordi den bruger mere avancerede teknikker end den simple opgaveskift implementeret af mange velkendte programmer (såsom DOS Shell fra MS-DOS 5.0). Med en simpel switch får det aktive program al CPU-tiden, og baggrundsapplikationer er fuldstændig frosne. Med kooperativ multitasking kan en applikation faktisk få så meget CPU-tid, som den finder passende. Alle applikationer deler CPU-tid og overfører med jævne mellemrum kontrol til den næste opgave.
Fordele ved cooperativ multitasking: ingen grund til at beskytte alle delte datastrukturer med objekter såsom kritiske sektioner og mutexes, hvilket forenkler programmering, især portering af kode fra single-tasking-miljøer til multitasking-miljøer.
Ulemper: alle applikationers manglende evne til at fungere i tilfælde af en fejl i en af dem, hvilket fører til fraværet af et opkald til operationen "giv CPU-tid". Den ekstremt vanskelige mulighed for at implementere en multitasking I/O-arkitektur i OS-kernen, som gør det muligt for processoren at udføre en opgave, mens en anden opgave har startet en I/O-operation og venter på dens afslutning.
En type multitasking, hvor operativsystemet selv overfører kontrol fra et eksekverbart program til et andet i tilfælde af færdiggørelse af I/O-operationer, forekomst af hændelser i computerhardwaren, udløb af timere og tidsudsnit eller kvitteringen af visse signaler fra et program til et andet. I denne form for multitasking kan processoren skiftes fra at udføre et program til at udføre et andet uden ønske fra det første program og bogstaveligt talt mellem to vilkårlige instruktioner i dets kode. Fordelingen af processortid udføres af procesplanlæggeren. Derudover kan hver opgave tildeles en vis prioritet af brugeren eller af selve operativsystemet, hvilket giver fleksibel kontrol over fordelingen af processortid mellem opgaverne (man kan f.eks. reducere prioriteringen af et ressourcekrævende program, derved reducere dens hastighed, men øge ydeevnen af baggrundsprocesser). Denne form for multitasking giver en hurtigere reaktion på brugerhandlinger.
Fordele:
Fejl:
Implementeret i sådanne operativsystemer som:
Tidsforsinkelsen fra at vække en tråd til at kalde den på processoren, hvor den er på listen over tråde klar til at køre. Opstår på grund af tilstedeværelsen af tråde med højere eller samme prioritet, som kører hele tiden.
Den negative effekt er, at der er en tidsforsinkelse fra at vække tråden, indtil den udfører den næste vigtige operation, som forsinker udførelsen af denne operation, og efter den, arbejdet med mange andre komponenter.
Sult skaber en flaskehals i systemet og forhindrer det i at presse maksimal ydeevne ud af det, kun begrænset af hardware-drevne flaskehalse.
Enhver sult ud over 100 % CPU-brug kan rettes ved at hæve den sultende tråds prioritet, muligvis midlertidigt.
Som regel, for at forhindre sult, kalder OS automatisk lavprioritetstråde, der er klar til eksekvering, selvom der er højprioritetstråde, forudsat at tråden ikke er blevet eksekveret i lang tid (~10 sekunder). Visuelt er dette billede velkendt for de fleste Windows-brugere - hvis tråden i et af programmerne sløjfedes på ubestemt tid, så fungerer frontvinduet fint, på trods af dette, tråden forbundet med frontvinduet, øger Windows prioritet. Resten af vinduerne er tegnet om med lange forsinkelser, portioner pr. sekund, fordi deres gengivelse i denne situation kun virker på grund af sultforebyggelsesmekanismen (ellers ville den sulte for evigt).
Den ikke-deterministiske rækkefølge for udførelse af to kodestrømme, der behandler de samme data og udføres i to forskellige tråde (opgaver). Det fører til afhængigheden af rækkefølgen og korrektheden af udførelsen af tilfældige faktorer.
Elimineret ved at tilføje nødvendige låse og synkroniseringsprimitiver . Det er normalt en let fikseret defekt (glemt lås ).
Tråd L har en lav prioritet, tråd M har en medium prioritet, og tråd H har høj prioritet. Tråd L opnår mutex'en, og mens den udføres, mens du holder mutex'en, afbrydes den af tråd M, som er vågnet af en eller anden grund og har en højere prioritet. Tråd H forsøger at erhverve mutex.
I den resulterende situation venter tråd H på tråd M for at fuldføre det aktuelle arbejde, fordi mens tråd M udføres, modtager lavprioritet tråd L ikke kontrol og kan ikke frigive mutex.
Elimineret ved at hæve prioriteten af alle tråde, der erhverver en given mutex, til den samme høje værdi i den periode, mutexen afholdes. Nogle mutex-implementeringer gør dette automatisk. Alternativt fremmes en tråd, der allerede har opnået mutex'en, efter et forsøg på samtidig at erhverve mutex'en af en højere prioritet tråd.
| Aspekter af operativsystemer | |||||
|---|---|---|---|---|---|
| |||||
| Typer |
| ||||
| Nucleus |
| ||||
| Procesledelse _ |
| ||||
| Hukommelseshåndtering og adressering | |||||
| Indlæsnings- og initialiseringsværktøjer | |||||
| skal | |||||
| Andet | |||||
| Kategori Wikimedia Commons Wikibooks Wiktionary | |||||