Göra flera saker samtidigt

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 16 mars 2021; kontroller kräver 9 redigeringar .

Multitasking ( engelska  multitasking ) är en egenskap hos operativsystemet eller körtidsmiljön för att ge möjligheten till parallell (eller pseudo- parallell ) bearbetning av flera uppgifter . Verklig multitasking av operativsystemet är endast möjligt i distribuerade datorsystem .

Det finns två typer av multitasking [1] :

Multithreading  är en specialiserad form av multitasking [1] .

Multitasking miljöegenskaper

Primitiva multitasking-miljöer ger ren "resursdelning", där varje uppgift tilldelas ett specifikt minnesområde, och uppgiften aktiveras med strikt definierade tidsintervall.

Mer avancerade multitasking-system allokerar resurser dynamiskt när en uppgift startar i minnet eller lämnar minnet, beroende på dess prioritet och på systemstrategin. Denna multitasking-miljö har följande funktioner:

Svårigheter att implementera en multitasking-miljö

Den största svårigheten med att implementera en multitasking-miljö är dess tillförlitlighet, uttryckt i minnesskydd, hantering av fel och avbrott , skydd mot frysningar och dödlägen .

Förutom att vara pålitlig måste en multitasking-miljö vara effektiv. Kostnaden för resurser för att underhålla den bör inte: störa processer, sakta ner deras arbete, kraftigt begränsa minnet.

Historik för multitasking-operativsystem

Till en början var implementeringen av multitasking-operativsystem ett allvarligt tekniskt problem, varför introduktionen av multitasking-system försenades, och användarna föredrog single-tasking-system under lång tid efter implementeringen.

Senare, efter uppkomsten av flera framgångsrika lösningar, började multitasking-miljöer att förbättras och används nu överallt.

För första gången implementerades multitasking av operativsystemet under utvecklingen av operativsystemet Multics ( 1964 ). Ett av de första multitasking-systemen var OS/360 (1966 [2] ), som användes för IBM-datorer och deras sovjetiska motsvarigheter ES EVM . Utvecklingen av systemet försenades kraftigt, och för första gången lade IBM fram en DOS med en enda uppgift för att tillfredsställa kunderna innan OS/360 togs i drift. Systemet har kritiserats på grund av låg tillförlitlighet och svårigheter att använda.

1969 , på basis av Multics, utvecklades UNIX- systemet med en ganska exakt algoritmisk lösning på problemet med multitasking. För närvarande har dussintals operativsystem skapats baserade på UNIX.

PDP -11- datorerna och deras sovjetiska SM-4- motsvarigheter använde multitasking-systemet RSX-11 (den sovjetiska motsvarigheten är SM EVM RTOS ), och TSX-PLUS tidsdistributionssystem, som ger begränsad multitasking-kapacitet och en fleranvändartid delningsläge, som för varje användare emulerar en RT-11 med en enda uppgift (sovjetisk analog - RAFOS ). Den senare lösningen var mycket populär på grund av den låga effektiviteten och tillförlitligheten hos ett fullfjädrat multitasking-system.

En snygg lösning visade sig vara operativsystemet VMS , som ursprungligen utvecklades för VAX-datorer (den sovjetiska motsvarigheten är SM-1700 ) som en utveckling av RSX-11.

Världens första multimediapersondator Amiga 1000 ( 1984 ) designades ursprungligen med fullt hårdvarustöd för förebyggande multitasking i realtid i AmigaOS . I det här fallet utfördes utvecklingen av hårdvara och mjukvara parallellt, vilket ledde till att när det gäller multitasking-schemaläggarkvantisering (1/50 sekund per kontextväxel), förblev AmigaOS oöverträffad på persondatorer under lång tid .

Multitasking tillhandahölls också av Microsoft i Windows operativsystem . Användningen av VMS-erfarenhet gav system med betydligt högre prestanda och tillförlitlighet. När det gäller multitasking-kontextbytetid (kvantisering) kan endast dessa operativsystem jämföras med AmigaOS och UNIX (och även dess ättlingar, såsom Linux-kärnan ).

Intressant nog kan multitasking implementeras inte bara i operativmiljön utan även i språkmiljön. Till exempel kräver specifikationerna för programmeringsspråken Modula-2 och Ada stöd för multitasking utanför alla operativsystem. Som ett resultat gjorde JPI / Clarions populära implementering av programmeringsspråket TopSpeed ​​​​Modula-2 under första hälften av 1990 -talet det möjligt att organisera olika typer av multitasking (samarbete och förebyggande - se nedan) för trådarna i en program inom ett så grundläggande operativsystem som MS-DOS . Detta gjordes genom att inkludera en kompakt uppgiftsschemaläggare i programmodulen , innehållande en timeravbrottshanterare [3] . Programmeringsspråk som har denna egenskap kallas ibland realtidsspråk [4] .

Typer av pseudo-parallell multitasking

Enkelt byte

En typ av multitasking där operativsystemet laddar två eller flera applikationer i minnet samtidigt, men endast huvudapplikationen ges CPU-tid. För att ett bakgrundsprogram ska köras måste det vara aktiverat. Sådan multitasking kan implementeras inte bara i operativsystemet, utan också med hjälp av task switcher-program. Känt i denna kategori är programmet DESQview , som kördes under DOS och släpptes först 1985.

Fördelar: du kan använda redan körda program skrivna utan multitasking i åtanke.

Nackdelar: omöjligt i icke-interaktiva system som fungerar utan mänsklig inblandning. Interaktionen mellan programmen är extremt begränsad.

Multitasking i samarbete eller samarbete

En typ av multitasking där nästa uppgift körs först efter att den aktuella uppgiften uttryckligen har förklarat sig redo att ge CPU-tid till andra uppgifter. Som ett specialfall antyds en sådan deklaration när man försöker fånga ett redan ockuperat mutex -objekt (Linux-kärnan), såväl som när man väntar på att nästa meddelande ska anlända från användargränssnittets delsystem (Windows-versioner upp till 3.x inklusive, samt 16-bitarsapplikationer i Windows 9x ).

Cooperativ multitasking kan kallas multitasking i "andra steget" eftersom den använder mer avancerade tekniker än den enkla uppgiftsväxling som implementeras av många välkända program (som DOS Shell från MS-DOS 5.0). Med en enkel switch får det aktiva programmet all CPU-tid, och bakgrundsapplikationer är helt frusna. Med kooperativ multitasking kan en applikation faktiskt ta så mycket CPU-tid som den passar. Alla applikationer delar CPU-tid och skickar regelbundet kontrollen till nästa uppgift.

Fördelar med samverkande multitasking: inget behov av att skydda alla delade datastrukturer med objekt som kritiska sektioner och mutexes, vilket förenklar programmering, särskilt portering av kod från miljöer med enkel uppgift till multitasking-miljöer.

Nackdelar: oförmågan hos alla applikationer att fungera i händelse av ett fel i en av dem, vilket leder till frånvaron av ett anrop till operationen "ge CPU-tid". Den extremt svåra möjligheten att implementera en multitasking I/O-arkitektur i OS-kärnan, vilket gör att processorn kan utföra en uppgift, medan en annan uppgift har initierat en I/O-operation och väntar på att den ska slutföras.

Förebyggande eller förebyggande multitasking ( realtid )

En typ av multitasking där operativsystemet självt överför kontrollen från ett körbart program till ett annat i händelse av slutförandet av I/O-operationer, förekomsten av händelser i datorns hårdvara, utgången av timers och tidssegment, eller kvittot av vissa signaler från ett program till ett annat. I denna typ av multitasking kan processorn växlas från att köra ett program till att köra ett annat utan att det första programmet önskas och bokstavligen mellan två instruktioner i dess kod. Fördelningen av processortid utförs av processplaneraren. Dessutom kan varje uppgift tilldelas en viss prioritet av användaren eller av operativsystemet självt, vilket ger flexibel kontroll över fördelningen av processortid mellan uppgifter (du kan till exempel minska prioritet för ett resurskrävande program, därigenom minskar dess hastighet, men ökar prestanda för bakgrundsprocesser). Denna typ av multitasking ger ett snabbare svar på användaråtgärder.

Fördelar:

Brister:

Implementerat i sådana operativsystem som:

Problemsituationer i multitasking-system

Svält

Tidsfördröjningen från att en tråd väcks till att den anropas på processorn, under vilken den finns i listan över trådar redo att köras. Uppstår på grund av närvaron av trådar med högre eller lika prioritet som är igång hela tiden.

Den negativa effekten är att det finns en tidsfördröjning från att tråden vaknar tills den utför nästa viktiga operation, vilket fördröjer utförandet av denna operation, och efter det, arbetet med många andra komponenter.

Svält skapar en flaskhals i systemet och hindrar det från att pressa maximal prestanda ur det, endast begränsat av hårdvarudrivna flaskhalsar.

Eventuell svält utöver 100 % CPU-användning kan åtgärdas genom att höja den svältande trådens prioritet, eventuellt tillfälligt.

Som regel, för att förhindra svält, anropar operativsystemet automatiskt lågprioriterade trådar redo för exekvering, även om det finns högprioriterade trådar, förutsatt att tråden inte har körts på länge (~10 sekunder). Visuellt är den här bilden välkänd för de flesta Windows-användare - om tråden i ett av programmen gick i loop på obestämd tid, så fungerar det främre fönstret bra, trots detta, tråden som är associerad med det främre fönstret, ökar Windows prioritet. Resten av fönstren ritas om med långa fördröjningar, delar per sekund, eftersom deras återgivning i denna situation bara fungerar på grund av svältförebyggande mekanism (annars skulle den svälta för alltid).

Race skick

Den icke-deterministiska exekveringsordningen för två kodströmmar som bearbetar samma data och exekveras i två olika trådar (uppgifter). Det leder till beroendet av ordningen och korrektheten av utförandet av slumpmässiga faktorer.

Elimineras genom att lägga till nödvändiga lås och synkroniseringsprimitiver . Det är vanligtvis en lätt åtgärdad defekt (glömt lås ).

Prioritetsinversion

Tråd L har låg prioritet, tråd M har medium prioritet och tråd H har hög prioritet. Tråd L hämtar mutexet, och när den körs medan mutexet hålls, avbryts den av tråden M, som har vaknat av någon anledning och har högre prioritet. Tråd H försöker få mutex.

I den resulterande situationen väntar tråd H på att tråd M ska slutföra det aktuella arbetet, för medan tråd M körs får lågprioritets tråd L inte kontroll och kan inte släppa mutex.

Elimineras genom att höja prioritet för alla trådar som förvärvar ett givet mutex till samma höga värde under den period mutexet hålls. Vissa mutex-implementeringar gör detta automatiskt. Alternativt främjas en tråd som redan har förvärvat mutexet efter ett försök att samtidigt förvärva mutexet av en tråd med högre prioritet.

Länkar

Anteckningar

  1. 1 2 [Herbert Schildt The Complete Java Reference, 7:e upplagan: Per. från engelska-M.: LLC "I. D. Williams, 2007, s. 253-254]
  2. Mealy GH, Witt BI, Clark WA Den funktionella strukturen för OS/360. IBM Systems Journal, 5, nr 1, 1966
  3. Beletsky Ya. TopSpeed: En utökad version av Modula-2-språket för IBMs persondatorer. - M .: "Engineering", 1993
  4. Young S. Algoritmiska språk i realtid