Käsitellä asiaa(tai tehtävä) on abstraktio, joka kuvaa käynnissä olevaa ohjelmaa.

Käyttöjärjestelmälle käsitellä asiaa edustaa työyksikköä, pyyntöä järjestelmäresurssien kulutukselle. Prosessinhallinnan alijärjestelmä ajoittaa prosessien suorittamisen eli prosessien suorittamisen. jakaa prosessoriaikaa useiden järjestelmässä samanaikaisesti olevien prosessien kesken, sekä käsittelee prosessien luomista ja tuhoamista, antaa prosesseille tarvittavat järjestelmäresurssit ja tukee prosessien välistä vuorovaikutusta.

Osa resursseista allokoidaan prosessille, kun se luodaan, ja osa allokoidaan dynaamisesti ajonaikaisten pyyntöjen perusteella. Prosessille voidaan osoittaa resursseja koko sen elinkaarelle tai vain tietylle ajanjaksolle. Näitä toimintoja suorittaessaan prosessinhallinnan alijärjestelmä on vuorovaikutuksessa muiden resurssienhallinnasta vastaavien käyttöjärjestelmän alijärjestelmien kanssa, kuten muistinhallintaalijärjestelmän, syöttö/tulostusalijärjestelmän ja tiedostojärjestelmän kanssa. Kun järjestelmässä suoritetaan useita itsenäisiä tehtäviä samanaikaisesti, syntyy ongelmia. lisäongelmia. Vaikka prosessit syntyvät ja suoritetaan asynkronisesti, niiden on ehkä oltava vuorovaikutuksessa, kuten tietoja vaihdettaessa. Prosessinopeuksien sovittaminen on myös erittäin tärkeää, jotta estetään kilpailuolosuhteet, joissa useat prosessit yrittävät muokata samaa tiedostoa, umpikuja tai muita törmäyksiä, joita tapahtuu resursseja jaettaessa. Prosessien synkronointi on yksi prosessinhallinnan alijärjestelmän tärkeimmistä toiminnoista.

Joka kerta kun prosessi päättyy, prosessinhallinnan alijärjestelmä sulkee kaikki tiedostot, joiden kanssa prosessi työskenteli, vapauttaen alueita RAM-muistista, joka on varattu prosessin koodeille, datalle ja järjestelmätietorakenteille. Kaikki mahdolliset käyttöjärjestelmäjonot ja resurssiluettelot, jotka sisältävät viittauksia lopetettavaan prosessiin, korjataan.

Moniohjelmoinnin tukemiseksi käyttöjärjestelmän on määriteltävä ja suunniteltava itselleen ne sisäiset työyksiköt, joiden kesken prosessori ja muut tietokoneen resurssit jaetaan. Se on muistettava moniohjelmointi on tapa järjestää laskentaprosessi, jossa tietokoneen muisti sisältää useita ohjelmia, jotka suoritetaan vuorotellen yhdellä prosessorilla.

Tällä hetkellä useimmat käyttöjärjestelmät määrittelevät kahdenlaisia ​​työyksiköitä. Suurempi työyksikkö, jota yleensä kutsutaan prosessiksi tai tehtäväksi, vaatii useita pienempiä töitä, joita kutsutaan säikeeksi tai säikeeksi.

Ilmeisesti mikä tahansa tietokonejärjestelmän toiminta koostuu jonkin ohjelman suorittamisesta. Siksi sekä prosessiin että säikeeseen liittyy tietty ohjelmakoodi, joka on suunniteltu näitä tarkoituksia varten suoritettavan moduulin muodossa. Jotta tämä ohjelmakoodi voidaan suorittaa, se on ladattava RAM-muistiin, ehkä jonkin verran varattu levytilaa tietojen tallentamiseen, pääsy syöttö-/tulostuslaitteisiin, esim. sarjaportti. Suorituksen aikana ohjelma saattaa myös tarvita pääsyn HI:iin, kuten tiedostoihin. Ja tietysti on mahdotonta suorittaa ohjelmaa ilman sitä CPU-aika, eli aika, jonka aikana prosessori suorittaa tietyn ohjelman koodit.

Järjestelmissä, joissa on sekä prosesseja että säikeitä, käyttöjärjestelmä pitää prosessia pyyntönä kuluttaa kaikentyyppisiä resursseja, paitsi yhden prosessorin aikaa. Käyttöjärjestelmä jakaa tämän viimeisen tärkeimmän resurssin muiden työyksiköiden - säikeiden kesken, jotka ovat saaneet nimensä, koska ne edustavat komentosekvenssejä (suoritussäikeitä).

Yksinkertaisimmassa tapauksessa prosessi koostuu yhdestä säikeestä, ja näin käsitettä "prosessi" tulkittiin 1980-luvun puoliväliin asti ja se on säilynyt samassa muodossa joissakin nykyaikaisissa käyttöjärjestelmissä. Tämän tyyppisissä järjestelmissä "virtauksen" käsite imeytyy täysin käsitteeseen "prosessi", ts. Jäljelle jää vain yksi työn ja resurssien kulutuksen yksikkö - prosessi. Moniohjelmointi suoritetaan tällaisissa käyttöjärjestelmissä prosessitasolla.

Prosessilla on kolme perustilaa: valmis, käynnissä ja estetty.

Yhden prosessorin järjestelmässä vain yksi prosessi voi olla käynnissä. Samanaikaisesti voi olla useita valmiita ja estettyjä prosesseja odottamassa joidenkin tapahtumien (esimerkiksi I/O) tapahtumista. Tässä tapauksessa valmiiden prosessien luettelo on järjestetty prioriteetin mukaan.

Jotta prosessit eivät häiritse resurssien allokointia ja vahingoittaisivat toistensa koodeja ja tietoja, käyttöjärjestelmän on päätettävä tärkein tehtävä– eristää yksi prosessi toisesta.

Tämän saavuttamiseksi käyttöjärjestelmä tarjoaa jokaiselle prosessille erillisen virtuaalisen osoitetilan, jotta mikään prosessi ei pääse suoraan käsiksi toisen prosessin komentoihin ja tietoihin.

Käsittele virtuaalista osoiteavaruutta on joukko osoitteita, joita prosessiohjelmamoduuli voi käsitellä.

Käyttöjärjestelmä kartoittaa prosessin virtuaalisen osoiteavaruuden prosessille varattuun fyysiseen muistiin.

Kun vuorovaikutusta tarvitaan, prosessit kääntyvät käyttöjärjestelmän puoleen, joka välittäjänä tarjoaa heille prosessien välisen viestinnän keinot - putkistot, postilaatikoita, jaetun muistin osiot ja jotkut muut.

Kuitenkin järjestelmissä, joissa ei ole säiettä, syntyy ongelmia järjestettäessä rinnakkaisia ​​laskelmia prosessin sisällä. Ja sellainen tarve saattaa ilmaantua. Itse asiassa moniohjelmoinnin myötä se kasvaa läpijuoksu järjestelmässä, mutta erillistä prosessia ei voi koskaan suorittaa nopeammin kuin yhden ohjelman tilassa (kaikki resurssien jakaminen vain hidastaa yhden osallistujan työtä johtuen lisäajasta, joka kuluu odottamaan resurssin saatavuutta). Yhden prosessin sisällä ajettavassa sovelluksessa voi kuitenkin olla sisäistä rinnakkaisuutta, mikä voisi periaatteessa mahdollistaa sen ratkaisun nopeuttamisen. Jos ohjelma tarjoaa esimerkiksi pääsyn ulkoiseen laitteeseen, niin tämän toimenpiteen aikana on mahdollista olla estämättä koko prosessin suorittamista, vaan jatkaa laskelmia ohjelman toisessa haarassa. Useiden töiden suorittaminen rinnakkain yhdessä interaktiivisessa sovelluksessa parantaa käyttäjien tehokkuutta. Näin ollen tekstieditorilla työskennellessä on toivottavaa pystyä yhdistämään uuden tekstin kirjoittaminen aikaa vieviin toimintoihin, kuten tekstin merkittävän osan uudelleenmuotoilu, asiakirjan tulostaminen tai sen tallentaminen paikalliselle tai etälevylle.

Säikeet syntyivät käyttöjärjestelmässä keinona rinnakkaista laskelmia. Tietenkin laskutoimitusten rinnakkaisongelma yhden sovelluksen sisällä voidaan ratkaista perinteisillä menetelmillä.

Ensinnäkin sovellusohjelmoija voi ottaa rinnakkaisuuden järjestämisen monimutkaisen tehtävän valitsemalla sovelluksesta tietyn välitysaliohjelman, joka ajoittain siirtää ohjauksen jollekin laskentahaaralle. Tässä tapauksessa ohjelma osoittautuu loogisesti erittäin hämmentäväksi, ja siinä on useita hallinnan siirtoja, mikä vaikeuttaa merkittävästi sen virheenkorjausta ja muokkaamista.

Toiseksi ratkaisuna on luoda useita prosesseja kullekin rinnakkaiselle työlle yhtä sovellusta varten. Tavallisten käyttöjärjestelmätyökalujen käyttäminen prosessien luomiseen ei kuitenkaan anna meidän ottaa huomioon sitä tosiasiaa, että nämä prosessit ratkaisevat yhden ongelman, mikä tarkoittaa, että niillä on paljon yhteistä keskenään - ne voivat työskennellä samojen tietojen kanssa, käyttää samaa koodia. ja niillä on samat ja samat käyttöoikeudet tietokonejärjestelmän resursseihin.

Käyttöjärjestelmässä tarvitaan prosessien rinnalle toinen mekanismi laskelmien rinnakkaisuudelle, joka ottaisi huomioon saman sovelluksen yksittäisten laskentahaarojen väliset läheiset yhteydet.

Näitä tarkoituksia varten nykyaikaiset käyttöjärjestelmät tarjoavat monisäikeisen mekanismin. Samalla otetaan käyttöön uusi työyksikkö - toteutuksen lanka ja käsite "prosessi" muuttaa merkitystään suuressa määrin. Käsite "säie" vastaa prosessorin peräkkäistä siirtymistä ohjelmakäskystä toiseen. Käyttöjärjestelmä jakaa prosessoriajan säikeiden kesken. Käyttöjärjestelmä määrittää prosessille osoitetilan ja joukon resursseja, jotka jaetaan kaikkien sen säikeiden kesken.

Yhden ohjelman järjestelmissä ei ole tarvetta ottaa käyttöön työyksikköä kuvaavaa käsitettä, koska resurssien jakamisessa ei ole ongelmaa.

Säikeiden luominen vaatii käyttöjärjestelmältä vähemmän lisäkustannuksia kuin prosessit. Toisin kuin eri kilpaileviin sovelluksiin kuuluvat prosessit, yhden prosessin kaikki säikeet kuuluvat aina samaan sovellukseen, joten käyttöjärjestelmä eristää säikeitä paljon vähemmän kuin prosessit perinteisessä moniohjelmajärjestelmässä. Kaikki yhden prosessin säikeet käyttävät yhteisiä tiedostoja, ajastimia, laitteita, samaa RAM-aluetta ja samaa osoiteavaruutta. Tämä tarkoittaa, että niillä on samat globaalit muuttujat. Koska jokainen säie voi käyttää mitä tahansa prosessin virtuaalista osoitetta, yksi säie voi käyttää toisen säikeen pinoa. Saman prosessin säikeiden välillä ei ole täydellistä suojaa, koska ensinnäkin se on mahdotonta ja toiseksi se ei ole välttämätöntä. Vuorovaikutuksen ja tiedonvaihdon järjestämiseksi säikeiden ei tarvitse päästä käyttöjärjestelmään ollenkaan; niiden on vain käytettävä jaettua muistia - yksi säie kirjoittaa tietoja ja toinen lukee niitä. Toisaalta virtaa erilaisia ​​prosesseja ovat edelleen hyvin suojassa toisiltaan.

Moniohjelmointi on tehokkaampaa säietasolla kuin prosessitasolla. Jokaisella säikeellä on oma ohjelmalaskuri ja pino. Useaksi säikeeksi suunniteltu tehtävä yhden prosessin sisällä voidaan suorittaa nopeammin, koska sen yksittäiset osat suoritetaan näennäisen rinnakkain (tai rinnakkain moniprosessorijärjestelmässä). Monisäikeistystä voidaan käyttää erityisen tehokkaasti hajautettujen sovellusten ajamiseen; esimerkiksi monisäikeinen palvelin voi suorittaa pyyntöjä useilta asiakkailta rinnakkain.

Säikeiden käyttö ei liity ainoastaan ​​haluun lisätä järjestelmän suorituskykyä rinnakkaislaskennan avulla, vaan myös tavoitteeseen luoda luettavampia, loogisempia ohjelmia. Useiden suoritussäikeiden käyttöönotto yksinkertaistaa ohjelmointia. Esimerkiksi kirjoittaja-lukijatehtävissä yksi säie kirjoittaa puskuriin ja toinen lukee siitä. Koska niillä on yhteinen puskuri, sinun ei pitäisi tehdä niitä erilliset prosessit. Toinen esimerkki säikeiden käytöstä on ohjata signaaleja, kuten näppäimistön keskeytyksiä (Del tai Break). Keskeytyssignaalin käsittelyn sijaan yksi säie on määritetty odottamaan jatkuvasti signaalien saapumista. Siten säikeiden käyttö voi vähentää käyttäjätason keskeytyksiä. Näissä esimerkeissä rinnakkaissuoritus ei ole yhtä tärkeää kuin ohjelman selkeys.

Suurin vaikutus monisäikeisen käsittelyn käyttöönotosta saavutetaan moniprosessorijärjestelmissä, joissa säikeet, mukaan lukien samaan prosessiin kuuluvat, voidaan suorittaa eri prosessoreilla todella rinnakkain (eikä näennäisen rinnakkain).

Luo prosessi Ensinnäkin se tarkoittaa prosessikuvaajan luomista, joka on yksi tai useampi tietorakenne, joka sisältää kaikki tiedot prosessista, jota käyttöjärjestelmä tarvitsee sen hallitsemiseksi. Tällaisia ​​tietoja voivat olla esimerkiksi prosessin tunniste, tiedot suoritettavan moduulin muistipaikasta, prosessin etuoikeusaste (prioriteetti ja käyttöoikeudet) jne.

Esimerkkejä prosessin kuvaajista ovat Task Control Block (TCB) OS/360:ssa, Process Control Block (PCB) OS/2:ssa, prosessikahva UNIXissa, objektiprosessi Windows NT:ssä.

Prosessikuvaajan luominen merkitsee uuden kilpailijan ilmaantumista laskentaresurssien hallintaan järjestelmässä. Tästä eteenpäin käyttöjärjestelmän on otettava huomioon uuden prosessin tarpeet resurssien allokoinnissa.

Prosessin luomiseen kuuluu suoritettavan ohjelman koodien ja tietojen lataaminen Tämä prosessi levyltä RAM-muistiin. Tätä varten käyttöjärjestelmän on tunnistettava tällaisen ohjelman sijainti levyllä, jaettava RAM uudelleen ja varattava muistia uuden prosessin suoritettavalle ohjelmalle. Sitten on tarpeen lukea ohjelma sille varatuille muistialueille ja mahdollisesti muuttaa ohjelman parametreja muistipaikan mukaan.

Virtuaalimuistilla varustetuissa järjestelmissä vain osa prosessikoodista ja tiedoista voidaan ladata alkuhetkellä, jotta loput voidaan "pumppata" tarpeen mukaan. On järjestelmiä, joissa prosessin luomisvaiheessa ei välttämättä tarvitse ladata koodeja ja tietoja RAM-muistiin, vaan suoritettava moduuli kopioidaan kyseisestä hakemistosta tiedostojärjestelmä, jossa se alun perin sijaitsi, vaihtoalueelle - erikoisalue prosessikoodien ja tietojen tallentamiseen varattu levy. Suorittaessaan kaikkia näitä toimintoja prosessinhallinnan alijärjestelmä on tiiviissä vuorovaikutuksessa muistinhallintaalijärjestelmän ja tiedostojärjestelmän kanssa.

Monisäikeisessä järjestelmässä, kun prosessi luodaan, käyttöjärjestelmä luo vähintään yhden suoritussäikeen kullekin prosessille. Säiettä luotaessa, aivan kuten prosessia luotaessa, käyttöjärjestelmä luo erityisen tietorakenteen - säikeen kuvaajan, joka sisältää säikeen tunnisteen, käyttöoikeudet ja prioriteettitiedot, säikeen tilan ja muuta tietoa. Alkutilassa säie (tai prosessi, jos puhumme järjestelmästä, jossa "säikeen" käsitettä ei ole määritelty) on keskeytetyssä tilassa. Suoritettavan säikeen valintahetki suoritetaan tässä järjestelmässä hyväksytyn prosessoriajan antamista koskevan säännön mukaisesti ja ottaen huomioon kaikki olemassa olevat Tämä hetki säikeitä ja prosesseja. Jos prosessikoodit ja data ovat swap-alueella, prosessisäikeen aktivoinnin välttämätön edellytys on myös RAM-muistin tilan olemassaolo sen suoritettavan moduulin lataamiseksi.

Monissa järjestelmissä säie voi pyytää käyttöjärjestelmää luomaan ns jälkeläisiä virtoja. Eri käyttöjärjestelmät rakentuvat lapsisäikeiden ja heidän vanhempiensa välisen suhteen eri tavalla. Esimerkiksi joissakin käyttöjärjestelmissä emosäikeen suoritus synkronoidaan sen jälkeläisten kanssa; erityisesti pääsäikeen valmistumisen jälkeen käyttöjärjestelmä voi lopettaa kaikkien sen jälkeläisten suorittamisen. Muissa järjestelmissä lapsisäikeet voivat suorittaa asynkronisesti suhteessa pääsäikeeseen. Jälkeläiset perivät tyypillisesti monia emovirtojensa ominaisuuksia. Monissa järjestelmissä lasten synnyttäminen on ensisijainen prosessi prosessien ja säikeiden luomiseen.

Prosessisuunnitteluun kuuluu seuraavien tehtävien ratkaiseminen:

■ suoritettavan prosessin muuttamisen ajankohdan määrittäminen;

■ valitaan suoritettava prosessi valmiiden prosessien jonosta;

■ "vanhojen" ja "uusien" prosessien kontekstien vaihtaminen.

Kaksi ensimmäistä ongelmaa on ratkaistu ohjelmisto, ja jälkimmäinen on suurelta osin laitteistopohjainen.

On olemassa monia erilaisia ​​prosessisuunnittelualgoritmeja, jotka ratkaisevat luetellut ongelmat eri tavoin, tavoittelevat erilaisia ​​tavoitteita ja tarjoavat erilaista moniohjelmoinnin laatua. Tämän algoritmisarjan joukossa tarkastellaan lähemmin kahta yleisintä algoritmien ryhmää: kvantisointiin perustuvat algoritmit ja prioriteettipohjaiset algoritmit.

Mukaisesti kvantisointiin perustuvat algoritmit, aktiivisessa prosessissa tapahtuu muutos, jos:

■ prosessi päättyi ja poistui järjestelmästä;

■ tapahtui virhe;

■ prosessi on siirtynyt odottavaan tilaan;

■ tälle prosessille varattu suorittimen aikaosa on käytetty loppuun.

Prosessi, joka on käyttänyt kvanttinsa loppuun, asetetaan "valmis"-tilaan ja odottaa, että sille tarjotaan uusi prosessoriaikakvantti, ja se valitaan suoritettavaksi tietyn säännön mukaisesti. uusi prosessi valmiista jonosta. Tällä tavalla mikään prosessi ei vie CPU:ta pitkään, minkä vuoksi kvantisointia käytetään laajalti aikajakojärjestelmissä.

Prosesseille allokoidut kvantit voivat olla samat kaikille prosesseille tai erilaisia. Yhdelle prosessille allokoidut kvantit voivat olla kiinteäarvoisia tai vaihdella prosessin eri jaksoissa. Prosessit, jotka eivät ole käyttäneet täysimääräisesti niille allokoitua kvanttia (esimerkiksi I/O-toiminnan vuoksi), voivat saada korvauksen etuoikeuksien muodossa myöhemmän ylläpidon yhteydessä. Valmiiden prosessien jono voidaan järjestää eri tavoin: syklisesti säännön "first in, first out" (FIFO) mukaan tai "viimeinen sisään, ensimmäinen ulos" (LIFO) säännön mukaan.

SISÄÄN prioriteettipohjaiset algoritmit prosessin "prioriteetin" käsitettä käytetään.

Prioriteetti– Tämä on luku, joka kuvaa prosessin etuoikeusastetta resursseja käytettäessä tietokone, erityisesti CPU-aika: mitä korkeampi prioriteetti, sitä korkeammat oikeudet.

Prioriteetti voidaan ilmaista kokonais- tai murtolukuna, positiivisina tai negatiivisina arvoina. Mitä korkeammat oikeudet prosessilla on, sitä vähemmän se viettää aikaa jonoissa. Prioriteetti voidaan määrittää suoraan järjestelmänvalvojalta riippuen työn tärkeydestä tai maksetusta maksusta tai sen voi laskea käyttöjärjestelmä itse tiettyjen sääntöjen mukaisesti; se voi pysyä kiinteänä koko prosessin ajan tai muuttua ajan myötä. joku laki. Jälkimmäisessä tapauksessa prioriteetit kutsutaan dynaaminen.

Prioriteettialgoritmeja on kahdenlaisia: suhteellisia prioriteetteja käyttävät algoritmit ja absoluuttisia prioriteetteja käyttävät algoritmit.

Molemmissa tapauksissa prosessin valinta suoritettaviksi valmiusjonosta tapahtuu samalla tavalla: valitaan prosessi, jolla on korkein prioriteetti. Aktiivisen prosessin muutoshetken määrittämisongelma ratkaistaan ​​eri tavoin. Järjestelmissä suhteelliset prioriteetit Aktiivinen prosessi toimii, kunnes se poistuu itse prosessorista ja menee "esto"-tilaan (tai tapahtuu virhe tai prosessi päättyy). Järjestelmissä, joissa on ehdottomia prioriteetteja aktiivisen prosessin suoritus keskeytyy vielä yhdellä ehdolla: jos valmiiden prosessien jonoon ilmestyy prosessi, jonka prioriteetti on korkeampi kuin aktiivisen prosessin prioriteetti. Tässä tapauksessa keskeytetty prosessi siirtyy valmiustilaan.

Monissa käyttöjärjestelmissä ajoitusalgoritmit rakennetaan käyttämällä sekä kvantisointia että prioriteetteja. Esimerkiksi ajoitus perustuu kvantisointiin, mutta kvanttiarvo ja (tai) järjestys, jossa prosessi valitaan valmiiden jonosta, määräytyy prosessien prioriteettien mukaan.

Prosessin ajoitusmenettelyjä on kahta päätyyppiä: ennaltaehkäisevät ja ei-ennakoivat.

Ei-ennaltaehkäisevä moniajo(Non-preemptive multitasking) on ​​menetelmä prosessien ajoittamiseen, jossa aktiivinen prosessi toimii, kunnes se omasta aloitteestaan ​​antaa ohjauksen käyttöjärjestelmän ajoittimelle, jotta se valitsee jonosta toisen suoritettavaksi valmiin prosessin.

Ennaltaehkäisevä moniajo(Ennaltaehkäisevä moniajo) on menetelmä, jossa päätöksen prosessorin vaihtamisesta yhden prosessin suorittamisesta toisen suorittamiseen tekee käyttöjärjestelmän ajoittaja, ei itse aktiivinen tehtävä.

Käsitteet "ennaltaehkäisevä" ja "ei-ennaltaehkäisevä" identifioidaan toisinaan prioriteettien ja ei-prioriteettien käsitteisiin, mikä on täysin väärin, sekä absoluuttisen ja suhteellisen prioriteetin käsitteisiin, mikä on osittain väärin. Ennaltaehkäisevä ja ei-ennaltaehkäisevä moniajo ovat laajempia käsitteitä kuin prioriteettityypit. Tehtävien prioriteetteja voidaan käyttää tai ei saa käyttää sekä ennaltaehkäisevässä että ei-ennakoivassa ajoitusmenetelmissä. Siten prioriteettien käytön tapauksessa suhteellisten prioriteettien kurinalaisuus voidaan luokitella ei-ennaltaehkäisevää moniajoa käyttävien järjestelmien luokkaan, ja absoluuttisten prioriteettien kurinalaisuus voidaan luokitella ennaltaehkäisevää moniajoa käyttävien järjestelmien luokkaan. Ei-prioriteettinen ajoituskuri, joka perustuu yhtäläisten aikaosien allokointiin kaikille tehtäville, viittaa ennaltaehkäiseviin algoritmeihin.

Suurin ero ennaltaehkäisevän ja ei-ennaltaehkäisevän moniajon välillä on tehtävien ajoitusmekanismin keskittämisaste. klo ennaltaehkäisevä moniajo Tehtävien ajoitusmekanismi on täysin keskittynyt käyttöjärjestelmään ja ohjelmoija kirjoittaa sovelluksensa ilman huolta, että se suoritetaan rinnakkain muiden tehtävien kanssa. Tässä tapauksessa käyttöjärjestelmä toimii seuraavat toiminnot: määrittää hetken, jolloin aktiivinen tehtävä poistetaan suorituksesta, muistaa sen kontekstin, valitsee jonosta valmiita tehtäviä seuraavan ja käynnistää sen suoritusta varten lataamalla sen kontekstin. klo ei-ennaltaehkäisevä moniajo Ajoitusmekanismi on hajautettu järjestelmän ja sovellusohjelmien kesken. Sovellusohjelma, saatuaan ohjauksen käyttöjärjestelmästä, määrittää itse seuraavan iteraationsa valmistumishetken ja siirtää ohjauksen käyttöjärjestelmälle jonkin järjestelmäkutsun avulla, ja käyttöjärjestelmä muodostaa tehtäväjonoja ja valitsee seuraavan tehtävän suoritettavaksi joidenkin ohjeiden mukaisesti. algoritmi (esimerkiksi prioriteettien huomioon ottaminen) . Tämä mekanismi aiheuttaa ongelmia sekä käyttäjille että kehittäjille.

Käyttäjille tämä tarkoittaa, että järjestelmän hallinta menetetään mielivaltaiseksi ajaksi, jonka määrittää sovellus (ei käyttäjä). Jos sovellus käyttää liian paljon aikaa johonkin työhön, kuten levyn alustamiseen, käyttäjä ei voi siirtyä kyseisestä tehtävästä toiseen tehtävään, kuten tekstieditori, vaikka muotoilu jatkuisi taustalla. Tämä tilanne ei ole toivottava, koska käyttäjät eivät yleensä halua odottaa kauan, että kone suorittaa tehtävänsä. Siksi ennaltaehkäisevän käyttöympäristön sovelluskehittäjien on ajastimen toiminnot oletettu luotava sovelluksia, jotta ne suorittavat tehtävänsä pienissä osissa. Alustusohjelma voi esimerkiksi alustaa yhden levykkeen raidan ja palauttaa ohjauksen järjestelmään. Kun muut tehtävät on suoritettu, järjestelmä palauttaa ohjauksen muotoilijalle seuraavan kappaleen alustamiseksi. Tämä menetelmä ajan jakamiseksi tehtävien välillä toimii, mutta se vaikeuttaa merkittävästi ohjelmien kehittämistä ja asettaa lisää vaatimuksia ohjelmoijan pätevyydelle. Ohjelmoijan on varmistettava, että hänen ohjelmansa on "ystävällinen" muille sen kanssa samanaikaisesti käynnissä oleville ohjelmille ja antaa niille hallinnan melko usein. Äärimmäinen ilmentymä sovelluksen "epäystävällisyydestä" on sen jäätyminen, mikä johtaa yleiseen järjestelmän kaatumiseen. Järjestelmissä, joissa on ennaltaehkäisevä moniajo, tällaiset tilanteet ovat yleensä poissuljettuja, koska keskitetty ajoitusmekanismi poistaa jumiutuneen tehtävän suorituksesta.

Ajastintoimintojen jakaminen järjestelmän ja sovellusten kesken ei kuitenkaan aina ole haitta, ja tietyissä olosuhteissa voi olla etu, koska sen avulla sovelluskehittäjä voi suunnitella aikataulutusalgoritmin, joka sopii parhaiten tiettyyn kiinteään tehtäväjoukkoon. Koska kehittäjä itse määrittää ohjelmassa ajankohdan, jolloin ohjaus palautetaan, tämä eliminoi ohjelmien irrationaaliset keskeytykset "epämukavina" aikoina. Lisäksi tietojen jakamiseen liittyvät ongelmat ratkeavat helposti: tehtävä käyttää sitä yksinomaan jokaisen iteroinnin aikana ja on varma, että kukaan muu ei muuta näitä tietoja tänä aikana. Siirtojärjestelmien merkittävä etu on enemmän suuri nopeus siirtyminen tehtävästä tehtävään.

Esimerkki tehokkaasta ei-ennaltaehkäisevän moniajon käytöstä on NetWare-tiedostopalvelin, joka pitkälti tämän ansiosta on saavuttanut suuren tiedostotoiminnan nopeuden.

Kuitenkin lähes kaikki nykyaikaiset käyttöjärjestelmät, jotka keskittyvät korkean suorituskyvyn sovellusten suorittamiseen (UNIX, Windows NT, OS/2, VAX/VMS) toteuttavat ennaltaehkäisevän moniajoa. Viime aikoina vuoro on tullut pöytätietokoneiden käyttöjärjestelmiin. Ehkä tästä syystä ennaltaehkäisevää moniajoa kutsutaan usein totta.

7 vastausta

Tämä riippuu laitteistosta, koska et (ehkä) käytä teoreettinen tietokone, mutta fyysinen laitteisto, joten sinulla on rajalliset resurssit.

Lisäksi, vaikka käytät yli 5000 säiettä laitteistostasi riippuen, se voi olla paljon hitaampaa kuin 10 säiettä vastaava ohjelma. Mielestäni sinun pitäisi katsoa lankojen yhdistämistä.

Yleensä samanaikaisten säikeiden lukumäärä määräytyy käytössäsi olevien prosessorien ja CPU-ytimien (mukaan lukien hypersäikeistys) mukaan. Eli milloin tahansa käynnissä olevien säikeiden lukumäärä (käyttöjärjestelmässä) on yhtä suuri kuin "ytimien" lukumäärä.

Kuinka monta säiettä voit ajaa samanaikaisesti sovelluksessasi riippuu Suuri määrä tekijät. Paras numero(kevyt henkilö) olisi ytimien lukumäärä koneessa, mutta tietysti on kuin kukaan ei teeskentele (ei muuta sovellusta :).

Ollakseni rehellinen, sanoisin, että teen paljon monisäikeistystä .NET:ssä/Windowsissa, koska ihminen yleensä tekee enemmän "vahinkoa" kuin hyötyä, kun sinulla ei ole todellista ymmärrystä. NET:ssä on säiepooli, ja sinun on tietää, miten se toimii Windowsin lisäksi.

.NET 3.5/4.0:ssa kannattaa katsoa Task Parallel Library -kirjastoa, koska kirjasto pystyy paljon paremmin määrittämään, kuinka monta säiettä (jos ollenkaan) syntyy. TPL:n avulla threadpool saa suuren remontin ja on paljon älykkäämpi säikeiden kertomisessa ja tehtävien varastamisessa jne. Mutta yleensä työskentelet tehtävien, et säikeiden kanssa.

Tämä on monimutkainen alue, ja sen seurauksena .NET-alusta esitteli Tasks-sovelluksen, joka vie ohjelmoijat pois säikeistä ja mahdollistaa siten ajon aikana fiksun asian, kun taas ohjelmoija sanoi vain mitä haluaa eikä niinkään miten. Tämä.

Jokainen säiettä kuluttaa enemmän muistia (ydinpino, säieympäristön lohko, säikeen paikallinen, pino...). AFAIK Windowsissa ei ole nimenomaista rajaa, joten raja olisi muisti (luultavasti säiettäkohtainen pino).

SISÄÄN Linux-ketjut enemmän samankaltaisia ​​prosesseja (jaettu muisti) ja olet rajoitettu:

Cat /proc/sys/kernel/threads-max

Melko hyvä nyrkkisääntö suoritettaessa intensiivisiä tehtäviä on juosta sama määrä kuin fyysinen ydinmääräsi.

Kyllä, voit suorittaa useampia tehtäviä, mutta ne odottavat resursseja (tai säikeitä säikeessä) ja laatikkosi koosta riippumatta ei pysty allokoimaan kaikkia pääprosessoriresursseja 100 % säikeestä taustan/ muita prosesseja. Mitä enemmän tehtäviä luot, sitä enemmän säikeitä luot, koska niitä on enemmän kuin todellisia mahdollisia rinnakkaisia ​​säikeitä (1 per ydin), sitä enemmän resurssien hallintaa, jonotusta ja vaihtoa tehdään.

Testi, jonka suoritimme nyt, kun työskentelen käyttämällä virusmallia lisätehtäviä, osoitti, että optimaalinen taso on lähellä prosessorin pistemäärää. Tehtävät, jotka suoritettiin suhteessa yksi-yhteen fyysisellä ytimien lukumäärällä, kestivät noin 1 minuutin tehtävää kohden. Kun suorittimen laskuri kaksinkertaistui, tehtävän suorittamiseen kului aikaa 1 minuutista keskimäärin 5 minuuttiin. Se muuttuu geometrisesti hitaammaksi, mitä enemmän tehtäviä ydin käynnistää.

Joten jos sinulla on esimerkiksi 8 fyysistä ydintä, 8 tehtävän pitäisi olla nopein (ja TPL:ää käytettäessä olennaisesti 8 samanaikaista säiettä aktiivisessa prosessissa). Siellä on pääsäie tai prosessi, joka luo muita tehtäviä ja muita taustaprosesseja, mutta jos laatikko on melko eristetty resurssien käytön nauttimiseksi, nämä ovat melko vähäisiä.

Tehtävälisän ohjelmointipinta perustuu ydinlaskentaan, kun pureskelet tehtäviä jonosta tai luettelosta, joten kun otat sovelluksen käyttöön erikokoisiin laatikoihin, se mukautuu automaattisesti.

Määrittelemme tämän ohjelmallisesti

var CoreCount = System.Environment.ProcessorCount / 2;

Miksi jakaa kahdella, kysyt? Koska melkein kaikki nykyaikaiset prosessorit käytä loogisia ytimiä tai hypersäikeitä. Sinun pitäisi omalla testauksellasi havaita, että jos käytät loogista laskuria, kokonaisnopeus tehtävää kohden ja siten koko prosessi laskee merkittävästi. Fyysiset ytimet ovat avainasemassa. Emme voineet nähdä nopea tapa löytää fyysinen vs looginen mutta nopea arvostelu laatikoistamme on osoittanut, että tämä on jatkuvasti totta. YMMV, mutta tämä voi mennä melko nopeasti.

Pystyin ajamaan 4 säiettä samanaikaisesti nykyisellä vanhalla prosessorillani (2005). EVGA CPU polttimen käyttäminen ennen kuin prosessorin summeri soi. (Ohjelmoitu BIOS-valikossa). i-arvo ylitti 90 * c. Muista, että puhumme tietovirroista, jotka toimivat samanaikaisesti. Hyvä esimerkki olisi useiden ohjelmien avaaminen samanaikaisesti. Mutta kaiken kaikkiaan se riippuu siitä, kuinka hyvä prosessori on moniajossa. (toisin sanoen monia aktiivisia säikeitä voidaan käsitellä). Turvallisella tavalla testaus on ladata "ocscanner (By EVGA)" ja "CPU Thermometer" käyttämällä CPU:ta OC-skanneriin. Varmista testauksen aikana, että lämpötilasi ei nouse yli 90*c:n (tai missä tahansa lämpötilassa, jossa tunnet olevasi turvassa), ja katso, kuinka monta säiettä käytät prosessorillesi. aloita kahdella säikeellä, odota 3-5 minuuttia tarkkailemalla CPU:n lämpötilaa, lisää toinen lanka, toista. (ÄLÄ HYVÄKSY onneasi!!!) (ÄLÄ KOKEILE JOS CPU LÄMPÖMITTARI EI SAADA LÄMPÖTIÄSI!!!)

• Opetusohjelma

Tässä artikkelissa yritän kuvata terminologiaa, jota käytetään kuvaamaan järjestelmiä, jotka pystyvät suorittamaan useita ohjelmia rinnakkain, eli moniytiminen, moniprosessori, monisäikeinen. Eri tyypit IA-32 CPU:n rinnakkaisuus ilmestyi eri aika ja hieman epäjohdonmukaisessa järjestyksessä. Kaikessa tässä on melko helppoa hämmentyä, varsinkin kun otetaan huomioon, että käyttöjärjestelmät piilottavat huolellisesti yksityiskohtia vähemmän kehittyneiltä sovellusohjelmilta.

Artikkelin tarkoituksena on osoittaa, että moniprosessori-, moniytimis- ja monisäikeisten järjestelmien monilla mahdollisilla kokoonpanoilla luodaan mahdollisuuksia niillä toimiville ohjelmille sekä abstraktioon (erojen huomioimatta) että erityispiirteiden huomioon ottamiseen ( kyky ohjelmallisesti selvittää kokoonpano).

Varoitus artikkelissa olevista ®, ™ -merkeistä

Kommenttini selittää, miksi yritysten työntekijöiden tulisi käyttää tekijänoikeusilmoituksia julkisessa viestinnässä. Tässä artikkelissa minun piti käyttää niitä melko usein.

prosessori

Tietenkin vanhin, useimmin käytetty ja kiistanalainen termi on "prosessori".

SISÄÄN moderni maailma Prosessori on se, mitä ostamme kauniissa vähittäismyyntilaatikossa tai ei niin mukavassa OEM-paketissa. Jakamaton kokonaisuus, joka on asetettu emolevyn liitäntään. Vaikka liitintä ei olisi eikä sitä voi poistaa, eli jos se on tiukasti juotettu, se on yksi siru.

Mobiilijärjestelmissä (puhelimet, tabletit, kannettavat tietokoneet) ja useimmissa pöytätietokoneissa on yksi prosessori. Työasemissa ja palvelimissa on joskus kaksi tai useampi prosessori yhdellä emolevyllä.

Monipuolinen tuki keskusyksiköt yhdessä järjestelmässä vaatii useita muutoksia sen suunnitteluun. Vähintäänkin on varmistettava niiden fyysinen yhteys (varustaa useita pistorasioita emolevyllä), ratkaistaan ​​prosessorin tunnistamiseen liittyvät ongelmat (katso myöhemmin tässä artikkelissa sekä edellinen huomautukseni), muistin käyttöjen koordinointi ja toimitusten keskeyttäminen ( keskeytysohjaimen on kyettävä reitittämään keskeytykset useille prosessoreille) ja tietysti käyttöjärjestelmän tuki. Valitettavasti en löytänyt dokumentaarista mainintaa ensimmäisen moniprosessorijärjestelmän luomisesta Intel-prosessoreille, mutta Wikipedia väittää, että Sequent Computer Systems toimitti ne jo vuonna 1987 Intel 80386 -prosessoreilla. Useiden sirujen tuki yhdessä järjestelmässä on yleistymässä , alkaen Intel® Pentiumista.

Jos prosessoreita on useita, jokaisella niistä on oma liitin levyllä. Jokaisella niistä on täydelliset itsenäiset kopiot kaikista resursseista, kuten rekistereistä, suorituslaitteista, välimuistista. Heillä on yhteinen muisti - RAM. Muisti voidaan yhdistää niihin monin eri tavoin ja melko ei-triviaaleilla tavoilla, mutta tämä toinen tarina, joka ei kuulu tämän artikkelin piiriin. Tärkeää on, että suoritettaville ohjelmille tulee joka tapauksessa luoda illuusio homogeenisesta jaetusta muistista, joka on käytettävissä kaikilta järjestelmän prosessoreilta.

Valmiina nousuun! Intel® Desktop Board D5400XS

Ydin

Historiallisesti Intel IA-32:n moniytiminen ilmestyi myöhemmin kuin Intel® HyperThreading, mutta loogisessa hierarkiassa se tulee seuraavaksi.

Vaikuttaa siltä, ​​​​että jos järjestelmässä on enemmän prosessoreita, sen suorituskyky on korkeampi (tehtävissä, jotka voivat käyttää kaikkia resursseja). Kuitenkin, jos niiden välisen viestinnän kustannukset ovat liian korkeat, kaikki rinnakkaisuudesta saatavat hyödyt kuolevat yhteisen tiedon siirron pitkillä viiveillä. Juuri tätä havaitaan moniprosessorijärjestelmissä - sekä fyysisesti että loogisesti ne ovat hyvin kaukana toisistaan. varten tehokas kommunikointi Tällaisissa olosuhteissa on tarpeen keksiä erikoisväyliä, kuten Intel® QuickPath Interconnect. Energiankulutusta, loppuratkaisun kokoa ja hintaa tämä kaikki ei tietenkään vähennä. Pitäisi tulla apuun korkea integraatio komponentti - piirit, jotka suorittavat osia rinnakkaisohjelma, sinun on vedettävä ne lähemmäs toisiaan, mieluiten yhden kristallin päällä. Toisin sanoen yhden prosessorin tulisi järjestää useita ytimet, identtisiä toistensa kanssa kaikessa, mutta toimivat itsenäisesti.

Ensimmäiset Intelin moniytimiset IA-32-prosessorit esiteltiin vuonna 2005. Siitä lähtien keskimääräinen ytimien lukumäärä palvelimessa, työpöydässä ja nyt mobiilialustoille kasvaa tasaisesti.

Toisin kuin nämä kaksi yhden ytimen prosessorit Samassa järjestelmässä, jotka jakavat vain muistin, kaksi ydintä voivat myös jakaa välimuistit ja muut resurssit, jotka vastaavat vuorovaikutuksesta muistin kanssa. Useimmiten ensimmäisen tason välimuistit pysyvät yksityisinä (jokaisella ytimellä on omat), kun taas toinen ja kolmas taso voivat olla joko jaettuja tai erillisiä. Tämän järjestelmäorganisaation avulla voit vähentää tiedon toimitusviiveitä viereisten ytimien välillä, varsinkin jos ne työskentelevät yhteisen tehtävän parissa.

Mikrovalokuva neliytimisestä Intel-prosessorista koodinimeltään Nehalem. Yksittäiset ytimet on korostettu, jaettu välimuisti kolmas taso, samoin kuin QPI-linkit muihin prosessoreihin ja yhteiseen muistiohjaimeen.

Hyperketju

Noin 2002 asti ainoa tapa saada IA-32-järjestelmä, joka pystyy ajamaan kahta tai useampaa ohjelmaa rinnakkain, oli käyttää moniprosessorijärjestelmiä. Intel® Pentium® 4 sekä Xeon-linja koodinimeltään Foster (Netburst) esiteltiin uusi teknologia- hypersäikeet tai hypersäikeet, - Intel® HyperThreading (jäljempänä HT).

Ei mitään uutta auringon alla. HT on erikoistapaus mitä kirjallisuudessa kutsutaan simultaneous multithreading (SMT). Toisin kuin "oikeat" ytimet, jotka ovat täydellisiä ja itsenäisiä kopioita, HT:n tapauksessa vain osa sisäisistä solmuista, jotka ovat ensisijaisesti vastuussa arkkitehtonisen tilan - rekisterien - tallentamisesta, monistetaan yhdessä prosessorissa. Datan järjestämisestä ja käsittelystä vastaavat toimeenpanosolmut pysyvät yksittäisinä, ja niitä käyttää milloin tahansa enintään yksi säikeistä. Kuten ytimet, hypersäikeet jakavat välimuistit, mutta taso riippuu tietystä järjestelmästä.

En yritä selittää kaikkia SMT-mallien ja erityisesti HT-mallien etuja ja haittoja. Kiinnostunut lukija voi löytää melko yksityiskohtaista keskustelua tekniikasta monista lähteistä ja tietysti Wikipediasta. Huomautan kuitenkin seuraavan tärkeän kohdan, joka selittää nykyiset rajoitukset hypersäikeiden lukumäärälle todellisissa tuotteissa.

Viestirajoitukset

Missä tapauksissa "epäreilujen" moniytimien esiintyminen HT:n muodossa on perusteltua? Jos yksi sovellussäie ei pysty lataamaan kaikkia ytimen sisällä olevia suoritussolmuja, ne voidaan "lainata" toiselle säikeelle. Tämä on tyypillistä sovelluksille, joissa pullonkaula ei ole laskennassa, vaan tiedonhaussa, eli usein syntyy välimuistin menetyksiä ja joutuu odottamaan tietojen toimittamista muistista. Tänä aikana ydin ilman HT:ta pakotetaan toimimaan tyhjäkäynnillä. HT:n läsnäolon avulla voit nopeasti vaihtaa vapaat suorittavat solmut toiseen arkkitehtoniseen tilaan (koska se on monistettu) ja suorittaa sen käskyt. Tämä on latenssipiilotukseksi kutsutun tekniikan erikoistapaus, jossa yksi pitkä toiminto, jonka aikana hyödylliset resurssit ovat käyttämättömänä, peitetään muiden tehtävien rinnakkaisella suorittamisella. Jos sovelluksella on jo korkea ytimen resurssien käyttöaste, hypersäikeiden läsnäolo ei salli kiihdytystä - tässä tarvitaan "rehellisiä" ytimiä.

Tyypillisissä yleiskäyttöisiin konearkkitehtuureihin suunnitelluissa työpöytä- ja palvelinsovelluksissa on mahdollisuus rinnakkaisuuteen HT:n avulla. Tämä potentiaali on kuitenkin nopeasti käytetty. Ehkä tästä syystä lähes kaikissa IA-32-prosessoreissa laitteiston hypersäikeiden määrä ei ylitä kahta. Tyypillisissä skenaarioissa hyöty kolmen tai useamman hypersäikeen käytöstä olisi pieni, mutta meistin koon, sen virrankulutuksen ja kustannusten menetys on merkittävä.

Erilainen tilanne havaitaan tyypillisissä videokiihdyttimillä suoritettavissa tehtävissä. Siksi näille arkkitehtuureille on ominaista SMT-tekniikan käyttö suuremmalla määrällä säikeitä. Koska Intel® Xeon Phi -apuprosessorit (julkaistiin vuonna 2010) ovat ideologisesti ja genealogisesti melko lähellä näytönohjainkortteja, niissä saattaa olla neljä hypersäikeistys jokaisessa ytimessä - IA-32:lle ainutlaatuinen konfiguraatio.

Looginen prosessori

Kolmesta kuvatusta rinnakkaisuuden "tasosta" (prosessorit, ytimet, hypersäikeet) osa tai jopa kaikki saattavat puuttua tietystä järjestelmästä. Tähän vaikuttaa BIOS-asetukset(moniytiminen ja monisäikeisyys on poistettu käytöstä erikseen), mikroarkkitehtuuriominaisuudet (esimerkiksi HT puuttui Intel® Core™ Duosta, mutta se palautettiin Nehalemin julkaisun myötä) ja järjestelmätapahtumat (moniprosessoripalvelimet voivat sammuttaa vialliset prosessorit jos vikoja havaitaan ja jatka "lentämistä" jäljellä oleville). Miten tämä monitasoinen samanaikaisuuden eläintarha näkyy käyttöjärjestelmälle ja viime kädessä sovellussovelluksille?

Lisäksi mukavuuden vuoksi merkitsemme prosessorien, ytimien ja säikeiden lukumäärää tietyssä järjestelmässä kolmella ( x, y, z), Missä x on prosessorien lukumäärä, y- kunkin prosessorin ytimien lukumäärä ja z- hypersäikeiden lukumäärä kussakin ytimessä. Tästä eteenpäin kutsun tätä kolmeksi topologia- vakiintunut termi, jolla ei ole juurikaan tekemistä matematiikan alan kanssa. Tehdä työtä s = xyz määrittää kutsuttujen entiteettien määrän loogiset prosessorit järjestelmät. Se määrittelee riippumattomien sovellusprosessikontekstien kokonaismäärän jaetussa muistijärjestelmässä, jotka suoritetaan rinnakkain käyttöjärjestelmä pakko ottaa huomioon. Sanon "pakotettu", koska se ei voi ohjata kahden prosessin suoritusjärjestystä eri loogisissa prosessoreissa. Tämä pätee myös hypersäikeisiin: vaikka ne toimivat "peräkkäin" samassa ytimessä, tietyn järjestyksen määrää laitteisto, eivätkä ohjelmat voi havaita tai ohjata sitä.

Useimmiten käyttöjärjestelmä piilottaa loppusovelluksilta sen järjestelmän fyysisen topologian ominaisuudet, jossa se toimii. Esimerkiksi seuraavat kolme topologiaa: (2, 1, 1), (1, 2, 1) ja (1, 1, 2) - käyttöjärjestelmä edustaa niitä kahtena loogiset prosessorit, vaikka ensimmäisessä niistä on kaksi prosessoria, toisessa on kaksi ydintä ja kolmannessa vain kaksi säiettä.

Windows Tehtävienhallinta näyttää 8 loogista prosessoria; mutta kuinka paljon se on prosessoreissa, ytimissä ja hypersäikeissä?

Linux-top näyttää 4 loogista prosessoria.

Tämä on varsin kätevää sovellusten luojille - heidän ei tarvitse käsitellä laitteiston ominaisuuksia, jotka ovat usein heille merkityksettömiä.

Topologian ohjelmistomäärittely

Tietenkin topologian abstraktio yhdeksi määräksi loogisia prosessoreita joissakin tapauksissa luo tarpeeksi aihetta hämmennykseen ja väärinkäsityksiin (kiihkeissä Internet-kiistoissa). Tietokonesovellukset, jotka haluavat puristaa maksimaalisen suorituskyvyn laitteistosta, vaativat yksityiskohtaista hallintaa sen suhteen, missä niiden säikeet sijoitetaan: lähemmäksi toisiaan vierekkäisissä hypersäikeissä tai päinvastoin kauempana eri prosessoreissa. Viestinnän nopeus loogisten prosessorien välillä samassa ytimessä tai prosessorissa on paljon suurempi kuin prosessorien välisen tiedonsiirron nopeus. Myös työmuistin organisoinnin heterogeenisyyden mahdollisuus mutkistaa kuvaa.

Tietoa koko järjestelmän topologiasta sekä kunkin loogisen prosessorin sijainnista IA-32:ssa on saatavilla CPUID-käskyn avulla. Ensimmäisten moniprosessorijärjestelmien syntymisen jälkeen loogisen prosessorin tunnistusjärjestelmää on laajennettu useita kertoja. Tähän mennessä sen osat ovat CPUID:n arkkeissa 1, 4 ja 11. Mitä arkkia kannattaa tarkastella, voit määrittää seuraavasta artikkelista otetusta vuokaaviosta:

En kyllästy teitä tässä tämän algoritmin yksittäisten osien kaikilla yksityiskohdilla. Jos kiinnostusta löytyy, tämän artikkelin seuraava osa voidaan omisttaa tälle. Viittaan kiinnostuneen lukijan puoleen, joka tutkii tätä asiaa mahdollisimman yksityiskohtaisesti. Tässä kuvailen ensin lyhyesti mitä APIC on ja miten se liittyy topologiaan. Seuraavaksi tarkastellaan työskentelyä arkin 0xB (yksitoista tuumaa) kanssa desimaali), joka on päällä tällä hetkellä on "apico-rakennuksen" viimeinen sana.

APIC-tunnus

Paikallinen APIC (Advanced Programmable Interrupt Controller) on laite (nyt osa prosessoria), joka vastaa tiettyyn loogiseen prosessoriin tulevien keskeytysten käsittelystä. Jokaisella loogisella prosessorilla on oma APIC. Ja jokaisella niistä järjestelmässä on oltava yksilöllinen APIC ID -arvo. Tätä numeroa käyttävät keskeytysohjaimet osoitteisiin lähettäessään viestejä ja kaikki muut (esimerkiksi käyttöjärjestelmä) loogisten prosessorien tunnistamiseen. Tämän keskeytysohjaimen tekniset tiedot ovat kehittyneet Intel 8259 PIC:stä Dual PIC:n, APIC:n ja xAPIC:n kautta x2APIC:ksi.

Tällä hetkellä APIC ID:hen tallennetun numeron leveys on saavuttanut täydet 32 ​​bittiä, vaikka aiemmin se oli rajoitettu 16:een ja vielä aikaisemmin - vain 8 bittiin. Nykyään vanhojen aikojen jäänteet ovat hajallaan CPUID:ssä, mutta CPUID.0xB.EDX palauttaa kaikki 32 bittiä APIC ID:stä. Jokaisella loogisella prosessorilla, joka suorittaa itsenäisesti CPUID-käskyn, palautetaan eri arvo.

Perhesuhteiden selkeyttäminen

APIC ID -arvo itsessään ei kerro mitään topologiasta. Jotta voit selvittää, mitkä kaksi loogista prosessoria sijaitsevat fyysisen prosessorin sisällä (eli ne ovat "veli"hypersäikeitä), mitkä kaksi ovat saman prosessorin sisällä ja mitkä ovat täysin erilaisia ​​​​prosessoreita, sinun on verrattava niiden APIC ID -arvoja. Suhteen asteesta riippuen jotkut heidän osistaan ​​osuvat yhteen. Nämä tiedot sisältyvät CPUID.0xB-alilistoihin, jotka on operandikoodattu ECX:ssä. Jokainen niistä kuvaa yhden EAX:n topologiatason bittikentän sijainnin (tarkemmin sanoen kuinka monta bittiä APIC ID:ssä on siirrettävä oikealle, jotta se voidaan poistaa alemmat tasot topologia), sekä tämän kerroksen tyyppi - hyperthread, ydin tai prosessori - ECX:ssä.

Saman ytimen sisällä sijaitsevilla loogisilla prosessoreilla on samat APIC ID-bitit paitsi SMT-kenttään kuuluvat. Samassa prosessorissa sijaitseville loogisille prosessoreille kaikki bitit paitsi Core- ja SMT-kentät. Koska CPUID.0xB:n aliarkkien määrä voi kasvaa, tämä kaava mahdollistaa topologioiden kuvauksen tukemisen suuremmalla määrällä tasoja, jos tarvetta tulevaisuudessa ilmenee. Lisäksi on mahdollista ottaa käyttöön välitasoja olemassa olevien tasojen välille.

Tärkeä seuraus tämän järjestelmän organisoinnista on, että järjestelmän kaikkien loogisten prosessorien kaikkien APIC-tunnusten joukossa voi olla "reikiä", ts. ne eivät mene peräkkäin. Esimerkiksi moniytimisessä prosessorissa, jossa HT on pois päältä, kaikki APIC ID:t voivat osoittautua parillisiksi, koska vähiten merkitsevä bitti, joka vastaa hypersäikeen numeron koodaamisesta, on aina nolla.

Huomaan, että CPUID.0xB ei ole ainoa tiedonlähde käyttöjärjestelmän käytettävissä olevista loogisista prosessoreista. Luettelo kaikista sen käytettävissä olevista prosessoreista sekä niiden APIC ID -arvot on koodattu MADT ACPI -taulukkoon.

Käyttöjärjestelmät ja topologia

Käyttöjärjestelmät tarjoavat tietoa loogisten prosessorien topologiasta sovelluksille, jotka käyttävät omia rajapintojaan.

SISÄÄN Linuxin tiedot Topologiatiedot sisältyvät /proc/cpuinfo-pseudotiedostoon sekä dmidecode-komennon ulostuloon. Alla olevassa esimerkissä suodatan cpuinfon sisällön jossain neliydinjärjestelmässä ilman HT:tä, jättäen vain topologiaan liittyvät merkinnät:

Piilotettu teksti

ggg@shadowbox:~$ cat /proc/cpuinfo |grep "prosessori\|fyysinen\ tunnus\|sisarukset\|ydin\|ytimet\|apicid" prosessori: 0 fyysistä tunnus: 0 sisaruksia: 4 ydintä: 0 prosessoriytimiä: 2 apicid: 0 alkuperäinen apicid: 0 prosessori: 1 fyysinen tunnus: 0 sisaruksia: 4 ydintunnus: 0 prosessoriytimiä: 2 apicid: 1 alkuperäinen apicid: 1 prosessori: 2 fyysinen tunnus: 0 sisaruksia: 4 ydintunnus: 1 prosessoriytimiä: 2 apicid: 2 alkuperäinen apicid: 2 prosessori: 3 fyysinen tunnus: 0 sisaruksia: 4 ydintunnus: 1 prosessoriytimiä: 2 apicid: 3 alkuapitsid: 3

FreeBSD:ssä topologia raportoidaan sysctl-mekanismin kautta muuttujassa kern.sched.topology_spec XML-muodossa:

Piilotettu teksti

user@host:~$ 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 THREAD ryhmäSMT ryhmä 2, 3 THREAD ryhmäSMT ryhmä 4, 5 THREAD ryhmäSMT ryhmä 6, 7 THREAD ryhmäSMT ryhmä

MS Windows 8:ssa topologiatiedot näkyvät Task Managerissa.

Tämä on neljäs artikkeli "Breaking the Windows Limits" -sarjassa, jossa puhun Windowsin perusresurssien rajoituksista. Tällä kertaa aion keskustella kanssasi Windowsin tukemien säikeiden ja prosessien enimmäismäärän rajoituksista. Kuvaan tässä lyhyesti säikeen ja prosessin välistä eroa, kyselysäikeen rajoitusta, ja sitten puhumme prosessiin liittyvistä rajoituksista. Ensinnäkin päätin puhua säikeiden rajoituksista, koska jokaisessa aktiivisessa prosessissa on vähintään, yhdellä säikeellä (prosessilla, joka on poistunut mutta jonka viite on tallennettu toisen prosessin tarjoamaan käsittelijään, ei ole säiettä), joten prosessin rajat ovat suoraan riippuvaisia ​​taustalla olevista säikeiden rajoista.

Toisin kuin joissakin UNIX-versioissa, useimmilla Windows-resursseilla ei ole kiinteää rajaa käyttöjärjestelmään rakennusvaiheessa, vaan ne ovat rajoitettuja käyttöjärjestelmän käytettävissä olevien taustalla olevien resurssien perusteella, joista keskustelin aiemmin. Esimerkiksi prosessit ja säikeet vaativat itselleen fyysistä muistia, virtuaalimuistia ja poolimuistia, joten tietyssä Windows-järjestelmässä luotavien prosessien ja säikeiden määrä määräytyy lopulta jonkin näistä resursseista riippuen siitä, miten nämä prosessit tai säikeet luotiin ja mikä taustalla olevista resurssirajoista saavutetaan ensin. Siksi suosittelen, että luet aiemmat artikkelini, jos et ole jo tehnyt niin, koska seuraavaksi viittaan käsitteisiin, kuten varattu muisti, varattu muisti ja järjestelmämuistiraja, joista puhuin aiemmissa artikkeleissani:

Prosessit ja säikeet
Windows-prosessi on pohjimmiltaan säilö, joka tallentaa komentokoodin suoritettavasta tiedostosta. Se edustaa ytimen prosessiobjektia, ja Windows käyttää tätä prosessiobjektia ja siihen liittyviä tietorakenteita tallentaakseen ja ylläpitääkseen tietoja suoritettava koodi sovellukset. Esimerkiksi prosessilla on virtuaalinen osoiteavaruus, johon sen yksityiset ja julkiset tiedot on tallennettu ja johon suoritettava kuva ja siihen liittyvät tiedot DLL:t. Windows käyttää diagnostiikkatyökaluja tallentaakseen tietoja prosessin resurssien käytöstä, mikä auttaa seuraamaan ja suorittamaan pyyntöjä, ja tallentaa prosessin viittaukset käyttöjärjestelmäobjekteihin prosessin hallintataulukkoon. Prosessit toimivat suojauskontekstin kanssa, jota kutsutaan tunnukseksi, joka tunnistaa käyttäjätilin, ryhmän tili ja prosessille annetut oikeudet.

Prosessi sisältää yhden tai useamman säikeen, jotka todella suorittavat koodia prosessissa (teknisesti ei suorita prosesseja, vaan säikeet) ja se esitetään järjestelmässä ytimen säieobjekteina. On useita syitä, miksi sovellukset luovat säikeitä alkuperäisen aloitussäikensä lisäksi: 1) käyttöliittymällä varustetut prosessit luovat tyypillisesti säikeitä tehdäkseen työnsä ja pitävät pääsäikeen reagoivana käyttäjän syöttökomentoihin ja ikkunoiden hallintaan; 2) Sovellukset, jotka haluavat käyttää useita prosessoreita suorituskyvyn skaalaamiseen tai jotka haluavat jatkaa toimintaansa säikeiden pysähtyessä odottaen I/O:n synkronointia, luovat säikeitä hyödyntääkseen monisäikeistystä.

Viestirajoitukset
Säiettä koskevien perustietojen, mukaan lukien CPU-rekisterien tila, säikeen prioriteetti ja tiedot säikeen resurssien käytöstä, lisäksi jokaisella säikeellä on varattu osa prosessin osoiteavaruudesta, nimeltään pino, jota säie voi käyttää työmuisti ohjelmakoodin suorituksen aikana toimintoparametrien välittämiseen, paikallisten muuttujien ja funktiotulosten osoitteiden tallentamiseen. Näin ollen järjestelmän virtuaalimuistin tuhlaamisen välttämiseksi vain osa pinosta varataan aluksi tai osa siitä siirretään säikeeseen ja loput yksinkertaisesti varataan. Kun muistipinot kasvavat laskevassa järjestyksessä, järjestelmä sijoittaa muistin niin sanotut "suojasivut" pinon varatun osan ulkopuolelle, mikä varmistaa, että lisämuistia (kutsutaan pinonlaajennukseksi) varataan automaattisesti, kun sitä tarvitaan. Seuraavassa kuvassa näkyy, kuinka varattu pinoalue syvenee ja kuinka suojasivut liikkuvat pinon laajentuessa 32-bittisessä osoiteavaruudessa:

Suoritettavien kuvien Portable Executable (PE) -rakenteet määrittävät säikeen pinolle varatun ja alun perin varatun osoitetilan määrän. Oletuksena linkkijä varaa 1 Mt ja varaa yhden sivun (4KB), mutta kehittäjät voivat muuttaa näitä arvoja joko muuttamalla PE-arvoja kommunikoidessaan ohjelmansa kanssa tai kutsumalla CreateTread-funktiota erillisessä säikeessä. Voit käyttää Visual Studion mukana tulevaa apuohjelmaa, kuten Dumpbinia, tarkastellaksesi suoritettavan ohjelman asetuksia. Tässä ovat tulokset Dumpbinin suorittamisesta /headers-vaihtoehdolla uuden Visual Studio -projektin luomassa suoritettavassa tiedostossa:

Muunnetaan numerot heksadesimaalijärjestelmä calculus, voit nähdä, että pinon varannon koko on 1 Mt ja varattu muistialue on 4 kt; käyttämällä uusi apuohjelma Sysinternalsista nimeltä MMap, voit liittää tähän prosessiin ja tarkastella sen osoiteavaruutta ja näin nähdä prosessille alun perin varatun pinomuistisivun, suojasivun ja muun varatun pinomuistin:

Koska jokainen säiettä kuluttaa osan prosessin osoiteavaruudesta, prosesseilla on perusrajoitus säikeiden lukumäärälle, jonka ne voivat luoda, mikä on yhtä suuri kuin niiden osoiteavaruuden koko jaettuna säikeen pinon koolla.

32-bittisten streamien rajoitukset
Vaikka prosessilla ei olisi lainkaan koodia tai dataa ja koko osoiteavaruus voitaisiin käyttää pinoihin, 32-bittinen prosessi, jonka oletusosoiteavaruus on 2 tavua, voisi luoda enintään 2048 säiettä. Tässä ovat tulokset Testlimitistä, joka toimii 32-bittisessä Windowsissa valinnalla -t (säikeen luominen), mikä vahvistaa tämän rajoituksen olemassaolon:

Jälleen kerran, koska osa osoiteavaruudesta oli jo käytetty koodille ja alkukekomuistille, kaikki 2 Gt ei ollut käytettävissä säikeen pinoissa, joten luotujen säikeiden kokonaismäärä ei voinut saavuttaa teoreettista 2048 säiettä.

Yritin ajaa Testlimitin kanssa lisävaihtoehto, joka antaa sovellukselle laajennetun osoitetilan toivoen, että jos sille annetaan enemmän kuin 2 Gt osoiteavaruutta (esimerkiksi 32-bittisissä järjestelmissä, tämä saavutetaan suorittamalla sovellus /3GB- tai /USERVA-vaihtoehdolla käynnistykselle. ini, tai vastaava BCD-vaihtoehto Vistassa ja myöhemmässä lisäysservassa), se käyttää sitä. 32-bittisille prosesseille on varattu 4 Gt osoitetilaa käytettäessä 64-bittisessä Windowsissa, joten kuinka monta säiettä 64-bittisessä Windowsissa toimiva 32-bittinen Testlimit voi luoda? Aiemmin keskustellemme perusteella vastauksen pitäisi olla 4096 (4 Gt jaettuna 1 Mt), mutta käytännössä tämä luku on paljon pienempi. Tässä on 32-bittinen Testlimit, joka toimii 64-bittisessä Windows XP:ssä:

Syy tähän eroon on siinä, että kun suoritat 32-bittistä sovellusta 64-bittisessä Windowsissa, se on käytännössä 64-bittinen prosessi, joka suorittaa 64-bittistä koodia 32-bittisten säikeiden puolesta, ja siksi sillä on - säikeen muistialueet on varattu 64- ja 32-bittisille säikeille. 64-bittiselle pinolle on varattu 256 kt (poikkeuksia ovat ennen Vistaa julkaistut käyttöjärjestelmät, joissa 64-bittisten säikeiden pinon alkuperäinen koko on 1 Mt). Koska jokainen 32-bittinen säiettä alkaa 64-bittisessä tilassa ja pinon koko, joka sille varataan käynnistyksen yhteydessä, on suurempi kuin sivun koko, useimmissa tapauksissa näet, että 64-bittisen säikeen pinolle on varattu vähintään 16 kt. Tässä on esimerkki 32-bittisen virran 64- ja 32-bittisistä pinoista (32-bittisen pinon nimi on "Wow64"):

32-bittinen Testlimit pystyi luomaan 3204 säiettä 64-bittiseen Windowsiin, mikä selittyy sillä, että jokainen säie käyttää pinolle 1 Mt + 256 kt osoitetilaa (poikkeus on jälleen Windows-versiot Vistalle, jossa käytetään 1 Mt + 1 Mt). Sain kuitenkin erilaisen tuloksen, kun suoritin 32-bittistä Testlimitiä 64-bittisessä Windows 7:ssä:

Erot Windows XP:n ja Windows 7:n tulosten välillä johtuvat Windows Vistan osoitetilan allokointimallin, Address Space Layout Randomizationin (ASLR), satunnaisemmasta luonteesta, mikä johtaa pirstoutumiseen. Satunnaista DLL-lataus, säikeiden pino ja sijoitus dynaaminen muisti, auttaa parantamaan suojausta haittaohjelmia vastaan. Kuten näet seuraavassa VMMap-ohjelman tilannekuvassa, sisään testijärjestelmä Osoitetilaa on edelleen 357 Mt käytettävissä, mutta suurin vapaa lohko on 128 kt, mikä on vähemmän kuin 32-bittisen pinon vaatima 1 Mt:

Kuten totesin, kehittäjä voi ohittaa oletuspinon varauskoon. Yksi mahdollisia syitä Tämä voidaan tehdä osoitetilan tuhlaamisen välttämiseksi, kun tiedetään etukäteen, että säikeen pino käyttää aina vähemmän kuin oletusarvo 1 Mt. Testlimit PE -kuva käyttää oletuksena 64 kt:n pinovarauskokoa, ja kun määrität -n-vaihtoehdon yhdessä -t-vaihtoehdon kanssa, Testlimit luo säikeitä, joiden pinokoko on 64 kt. Tässä on tulos tämän apuohjelman suorittamisesta järjestelmässä, jossa on 32-bittinen Windows XP ja 256 Mt RAM (suoritin tämän testin erityisesti heikko järjestelmä, korostaa tätä rajoitusta):

Tässä on syytä huomata, että tapahtui toinen virhe, mikä tarkoittaa, että tässä tilanteessa syy ei ole osoiteavaruudessa. Itse asiassa 64 kt:n pinojen pitäisi tarjota noin 32 000 säiettä (2Gb/64Kb = 32768). Mikä rajoitus sitten ilmestyi tässä tapauksessa? Jos tarkastelet mahdollisia ehdokkaita, mukaan lukien varattu muisti ja pooli, ne eivät anna mitään vihjeitä vastauksen löytämiseen tähän kysymykseen, koska kaikki nämä arvot ovat rajojensa alapuolella:

Löydämme vastauksen osoitteesta lisäinformaatio muistista ytimen debuggerissa, joka ilmoittaa meille vaaditun rajan, joka liittyy käytettävissä olevaan pysyvään muistiin, jonka koko määrä on käytetty loppuun:

Käytettävissä oleva pysyvä muisti on fyysistä muistia, joka on varattu tiedoille tai koodille, jonka on sijaittava RAM-muistissa. Sivuttamattoman poolin ja sivuttamattomien ajurien koot lasketaan itsenäisesti, kuten esimerkiksi RAM-muistissa I/O-toimintoja varten varattu muisti. Jokaisessa säikeessä on molemmat käyttäjätilan pinot, kuten olen jo keskustellut, mutta niillä on myös etuoikeutettu-tilan (ydintilan) pino, jota käytetään, kun säikeet toimivat ydintilassa, kuten suorittavat järjestelmäkutsuja. Kun säiettä on aktiivinen, sen ydinpino kiinnitetään muistiin, jotta säie voi suorittaa ytimessä koodia, josta tarvittavat sivut eivät välttämättä puuttu.

Perusydinpino vie 12 kt 32-bittisessä Windowsissa ja 24 kt 64-bittisessä Windowsissa. 14225 säiettä vaativat noin 170 megatavua pysyvää muistia, mikä on täsmälleen niin paljon vapaata muistia tässä järjestelmässä, kun Testlimit ei ole käytössä:

Kun käytettävissä olevan järjestelmämuistin raja on saavutettu, monet perustoiminnot alkaa epäonnistua virheen takia. Esimerkiksi tässä on virhe, jonka sain, kun kaksoisnapsautin pikakuvaketta Internet Explorer sijaitsee työpöydällä:

Kuten odotettiin, Testlimit pystyi luomaan 6 600 säiettä 64-bittisessä Windowsissa, jossa on 256 Mt RAM-muistia - noin puolet niin monta säiettä kuin se pystyi luomaan 32-bittisessä Windowsissa, jossa on 256 Mt RAM-muistia - ennen kuin käytettävissä oleva muisti loppui:

Syy, miksi käytin aiemmin termiä "perus" ydinpino, on se, että grafiikka- ja ikkunointitoiminnot suorittava säie saa "ison" pinon, kun se soittaa ensimmäisen kutsun, joka on yhtä suuri (tai suurempi kuin) 20 kt per 32-bittinen Windows ja 48 kt 64-bittisessä Windowsissa. Testlimit-säikeet eivät kutsu mitään tällaista API:ta, joten niissä on perusydinpinot.
64-bittisten streamien rajoitukset

Kuten 32-bittisissä säikeissä, 64-bittisissä säikeissä on oletusarvoisesti 1 Mt:n pinovaraus, mutta 64-bittisissä säikeissä on paljon enemmän käyttäjäosoitetilaa (8 Tt), joten sen ei pitäisi olla ongelma, kun on kyse suuren määrän luomisesta. langat. Silti on selvää, että pysyvä käytettävissä oleva muisti on edelleen potentiaalinen rajoitin. Testlimitin 64-bittinen versio (Testlimit64.exe) pystyi luomaan -n-vaihtoehdon kanssa ja ilman - noin 6 600 säiettä järjestelmään, jossa oli 64-bittinen Windows XP ja 256 Mt RAM, täsmälleen sama kuin 32-bittinen versio. luotu, koska käytettävissä olevan muistin raja saavutettiin. Kuitenkin järjestelmässä, jossa on 2 Gt RAM-muistia, Testlimit64 pystyi luomaan vain 55 000 säiettä, mikä on huomattavasti vähemmän kuin niiden säikeiden määrä, jotka tämä apuohjelma voisi luoda, jos rajoituksena olisi pysyvä käytettävissä oleva muisti (2 Gt / 24 kt = 89 000):

Tässä tapauksessa syynä on säikeelle varattu alkupino, joka saa järjestelmän loppumaan virtuaalinen muisti ja näyttöön tulee virhe, koska sivutustiedoston kapasiteetti ei ole riittävä. Kun varatun muistin määrä saavuttaa RAM-muistin koon, uusien säikeiden luontinopeus laskee merkittävästi, koska järjestelmä alkaa "luistaa", aiemmin luotuja säikeipinoja aletaan sivuttaa sivutiedostoon, jotta uusille säikeipinoille tulee tilaa, ja sivutiedoston täytyy kasvaa. Kun vaihtoehto -n on käytössä, tulokset ovat samat, koska varatun pinomuistin alkuperäinen määrä pysyy samana.

Prosessin rajoitukset
Windowsin tukemien prosessien määrän pitäisi luonnollisesti olla pienempi kuin säikeiden lukumäärä, koska jokaisessa prosessissa on yksi säie ja prosessi itsessään aiheuttaa lisäresurssien kulutusta. 32-bittinen Testlimit, joka toimii järjestelmässä, jossa on 64-bittinen Windows XP ja 2 Gt järjestelmämuistia, luo noin 8400 prosessia:

Jos katsot ytimen virheenkorjauksen tulosta, käy selväksi, että tässä tapauksessa käytettävissä olevan muistin raja on saavutettu:

Jos prosessi käyttää pysyvää käytettävissä olevaa muistia vain etuoikeutetun tilan säikeen pinoon, Testlimit pystyisi luomaan monia yli 8400 säiettä 2 Gt:n järjestelmään. Tämän järjestelmän vapaana olevan muistin määrä ilman Testlimitiä on 1,9 Gt:

Jakamalla Testlimitin käyttämän pysyvän muistin määrä (1,9 Gt) sen luomien prosessien määrällä, huomaamme, että jokaisessa prosessissa on 230 kt pysyvää muistia. Koska 64-bittinen ydinpino vie 24 kilotavua, prosessia kohden puuttuu noin 206 kt. Missä on loput käytetystä pysyvästä muistista? Kun prosessi luodaan, Windows varaa riittävästi fyysistä muistia toimittamaan sivuja vähimmäismäärän. Tämä tehdään sen varmistamiseksi, että prosessilla on kaikissa tilanteissa käytettävissään riittävästi fyysistä muistia, jotta se voi tallentaa tarvittavan määrän dataa sivujen vähimmäismäärän tuottamiseksi. Oletusarvoisesti työskentelysivujoukon koko on usein 200 kt, mikä voidaan tarkistaa helposti lisäämällä Minimum Working Set -sarake Process Explorer -ikkunaan:

Loput 6 kilotavua on pysyvää käytettävissä olevaa muistia, joka on varattu lisämuistille (englanninkielisestä ei-sivuttavasta muistista), johon itse prosessi on tallennettu. Prosessi 32-bittisessä Windowsissa käyttää hieman vähemmän pysyvää muistia, koska sen säikeen etuoikeutettu pino on pienempi.

Kuten käyttäjätilan säiepinoissa, prosessit voivat ohittaa oletusarvoisen työjoukon sivukoon käyttämällä SetProcessWorkingSetSize-toimintoa. Testlimit tukee valitsinta -n, joka yhdessä valitsimen -p kanssa sallii sinun asettaa työsivujoukon pienimmäksi mahdolliseksi kooksi 80 kb Testlimit-pääprosessin aliprosesseille. Koska aliprosessit tarvitsevat aikaa työskentelysivujoukkojensa vähentämiseen, Testlimit pysähtyy sen jälkeen, kun se ei enää pysty synnyttämään prosesseja, ja yrittää jatkaa toimintaansa, jolloin sen aliprosesseille on mahdollisuus suorittaa. Testlimitillä, joka käynnistettiin parametrilla -n Windows 7:llä ja 4 Gt RAM-muistilla varustetussa järjestelmässä, on eri raja kuin pysyvän käytettävissä olevan muistin raja - varatun järjestelmämuistin raja:

Alla olevassa kuvakaappauksessa näet, että ytimen virheenkorjausohjelma ei raportoi vain, että varattu järjestelmän muistiraja on saavutettu, vaan myös, että tämän rajan saavuttamisen jälkeen on tapahtunut tuhansia muistinvarausvirheitä, sekä virtuaalisia että muistia. sivuttu pooli (varattu järjestelmämuistin raja saavutettiin itse asiassa useita kertoja, koska sivutiedoston kapasiteetin puutteesta johtuvan virheen sattuessa sama määrä kasvoi, mikä lyhensi tätä rajaa):

Ennen Testlimitin suorittamista keskimääräinen muistivaraus oli noin 1,5 Gt, joten säikeet veivät noin 8 Gt varattua muistia. Siksi jokainen prosessi kulutti noin 8 Gt/6600 tai 1,2 MB. Ytimen debugger!vm-komennon tulos, joka näyttää jakelun oma muisti(englanninkielisestä yksityisestä muistista) jokaiselle prosessille, vahvistaa tämän laskelman oikeellisuuden:

Säikeen pinolle varatun muistin alkumäärällä, joka on kuvattu aiemmin, on vain vähän vaikutusta jäljellä oleviin muistinvarauspyyntöihin, joita tarvitaan prosessin osoiteavaruuden tietorakenteissa, sivutaulukon merkinnöissä, käsittelytaulukon merkinnöissä, prosessi- ja säieobjekteissa sekä sen omissa tiedoissa, jotka prosessi luo sen alustuksen aikana.

Kuinka monta prosessia ja säiettä riittää?
Siten vastaukset kysymyksiin "kuinka monta säiettä Windows tukee?" ja "kuinka monta prosessia voit suorittaa samanaikaisesti Windowsissa?" toisiinsa. Sen lisäksi, että säikeet määrittävät pinon koon ja kuinka prosessit määrittävät niiden vähimmäistyösivujoukon vivahteita, kaksi päätekijää, jotka määrittävät vastaukset näihin kysymyksiin missä tahansa järjestelmässä, ovat fyysisen muistin määrä ja järjestelmän muistin varausraja. Joka tapauksessa, jos sovellus luo tarpeeksi säikeitä tai prosesseja lähestyäkseen näitä rajoja, sen kehittäjän tulee harkita uudelleen kyseisen sovelluksen suunnittelua, koska aina on erilaisia ​​tapoja saavuttaa sama tulos kohtuullisella määrällä prosesseja. Esimerkiksi sovelluksen skaalauksen päätavoite on pitää käynnissä olevien säikeiden määrä yhtä suurena kuin suorittimien lukumäärä, ja yksi tapa saavuttaa tämä on siirtyä synkronisesta I/O:sta asynkroniseen täydennysportteihin, minkä pitäisi auttaa pitämään käynnissä olevien säikeiden lukumäärä, joka vastaa suorittimien määrää.

Tässä artikkelissa puhumme aiheista, kuten prosesseja ja säikeitä, prosessikuvaajat, puhutaan virtojen synkronointi ja kosketetaan kaikkien suosikkia Windowsin tehtävähallinta.

Koko olemassaolon ajan käsitellä asiaa sen suoritus voidaan keskeyttää ja jatkaa monta kertaa. Suorituksen jatkamiseksi käsitellä asiaa, on tarpeen palauttaa sen toimintaympäristön tila. Käyttöympäristön tila näytetään rekisterien ja ohjelmalaskurin tilalla, prosessorin toimintatilalla, tiedostojen avaamisosoittimilla, keskeneräisten I/O-toimintojen tiedoilla, tämän prosessin suorittamien järjestelmäkutsujen virhekoodilla jne. Tätä tietoa kutsutaan prosessikonteksti.

Jotta käyttöjärjestelmä voi hallita prosesseja, sillä on oltava kaikki tähän tarvittavat tiedot. Tätä tarkoitusta varten jokainen prosessi alkaa prosessin kahva.

Kuvaaja – erityistä tiedon rakenne, joka käynnistetään jokaiselle prosessille (tehtäväkuvaaja, tehtävänhallintalohko).

Yleensä kuvaaja sisältää seuraavat tiedot:

1. Prosessin tunnus.
2. Prosessityyppi (tai luokka), joka määrittää joitain resurssien hallintasääntöjä valvojalle.
3. Prosessin prioriteetti.
4. Tilamuuttuja, joka määrittää, missä tilassa prosessi on (valmis ajoon, käynnissä, odottaa I/O-laitetta jne.)
5. Suojattu muistialue (tai sellaisen vyöhykkeen osoite), johon tallennetaan prosessorirekisterien nykyiset arvot, jos prosessi keskeytyy ilman, että se on valmis. Tätä tietoa kutsutaan tehtävän konteksti.
6. Tiedot resursseista, joita prosessi omistaa ja/tai jolla on oikeus käyttää (osoittimet tiedostojen avaamiseen, tiedot odottavista I/O-operaatioista jne.).
7. Paikka (tai sen osoite) kommunikoinnin järjestämiseen muiden prosessien kanssa.
8. Käynnistysajan parametrit (ajankohta, jolloin prosessi tulee aktivoida, ja tämän toimenpiteen taajuus).
9. Jos tiedostonhallintajärjestelmää ei ole, tehtävän osoite levyllä sen alkuperäisessä tilassa ja osoite levyllä, jossa se puretaan RAM-muistista, jos se korvataan toisella.

Käsittelykahva Se sisältää kontekstiin verrattuna enemmän toiminnallista tietoa, jonka pitäisi olla helposti prosessisuunnittelun osajärjestelmän saatavilla. Prosessikonteksti sisältää vähemmän oleellista tietoa, ja käyttöjärjestelmä käyttää sitä vasta, kun keskeytettyä prosessia on päätetty jatkaa.

Kuvaajat, sijaitsevat pääsääntöisesti pysyvästi RAM-muistissa nopeuttaakseen valvojan työtä, joka järjestää ne listoiksi (jonoksi) ja näyttää muutokset prosessin tilassa siirtämällä vastaavaa kuvaajaa luettelosta toiseen.

Käyttöjärjestelmä ylläpitää jokaista tilaa (paitsi yhden prosessorin järjestelmän ajotilaa) vastaavaa luetteloa kyseisessä tilassa olevista tehtävistä. Odotustilassa voi kuitenkin olla useampi kuin yksi luettelo, mutta niin monta erityyppistä resurssia voi aiheuttaa odotustilan.

Esimerkiksi I/O-toiminnon suorittamista odottavia tiloja voi olla yhtä monta kuin järjestelmässä on I/O-laitteita.

Prosessit ja säikeet

Moniohjelmoinnin tukemiseksi käyttöjärjestelmän on määriteltävä ja suunniteltava itselleen ne sisäiset työyksiköt, joiden kesken prosessori ja muut tietokoneen resurssit jaetaan. Tällä hetkellä useimmat käyttöjärjestelmät määrittelevät kahdentyyppisiä työyksiköitä:

• Käsitellä asiaa(isompi työyksikkö).
• Virtaus(säie tai lanka) on pienempi työyksikkö, jonka prosessi vaatii suorittaakseen loppuun.
• Kun he puhuvat prosesseista, sitten he haluavat huomata, että käyttöjärjestelmä tukee heidän eristämistään: jokaisella prosessilla on oma virtuaalinen osoiteavaruutensa, jokaiselle prosessille on määritetty omat resurssinsa - tiedostot, ikkunat jne. Tällaista eristämistä tarvitaan prosessin suojaamiseksi toiselta, koska he, jakavat kaikki laskentajärjestelmän resurssit, kilpailevat keskenään.

Yleisesti prosessit eivät yksinkertaisesti liity toisiinsa millään tavalla ja voivat jopa kuulua eri käyttäjille, jotka jakavat saman tietokonejärjestelmä. Toisin sanoen prosessien tapauksessa käyttöjärjestelmä pitää niitä täysin riippumattomina ja itsenäisinä. Tässä tapauksessa käyttöjärjestelmä on vastuussa prosessien välisestä kilpailusta resursseista.

Prosessien nopeuden lisäämiseksi on mahdollista käyttää sisäistä rinnakkaisuutta itse prosesseissa. prosessit.

Esimerkiksi jotkin sovelluksen suorittamat toiminnot voivat vaatia melko paljon suorittimen käyttöä. Tässä tapauksessa, kun käyttäjä työskentelee vuorovaikutteisesti sovelluksen kanssa, käyttäjän on pakko odottaa pitkään tilatun toiminnon valmistumista, eikä hän voi hallita sovellusta ennen kuin toiminto on suoritettu loppuun asti. Tällaisia ​​tilanteita esiintyy melko usein esimerkiksi käsiteltäessä suuria kuvia graafisissa muokkausohjelmissa. Jos ohjelmistomoduulit, jotka suorittavat tällaisia ​​pitkiä toimintoja, olisi virallistettava itsenäisten "aliprosessien" muodossa ( purot), joka suoritetaan rinnakkain muiden "aliprosessien" kanssa, jolloin käyttäjällä on mahdollisuus suorittaa useita toimintoja rinnakkain yhden sovelluksen (prosessin) sisällä.

Seuraavat erot voidaan erottaa säikeitä prosesseista:

• Säikeiden käyttöjärjestelmän ei pitäisi järjestää täysimittaista virtuaalikoneen.
• Säikeillä ei ole omia resursseja, ne kehittyvät samassa virtuaalisessa osoiteavaruudessa ja voivat käyttää samoja tiedostoja, virtuaalisia laitteita ja muita resursseja kuin annettu prosessi.
• Ainoa asia, jonka säikeillä pitää olla, on CPU-resurssit. Yksiprosessorijärjestelmässä säikeet jakavat prosessoriajan toistensa kanssa samalla tavalla kuin normaalit prosessit, mutta moniprosessorijärjestelmässä ne voivat toimia samanaikaisesti, jos ne eivät kohtaa kilpailua muiden resurssien käytön vuoksi.

Tärkein asia, joka varmistaa monisäikeisyyden, on kyky suorittaa useita eri tyyppisiä toimintoja rinnakkain yhdessä sovellusohjelmassa. Miten se toteutetaan? tehokas käyttö CPU-resurssit ja tehtävien kokonaissuoritusaika vähenee.

Esimerkiksi jos pöytäprosessori tai tekstinkäsittelyohjelma on suunniteltu monisäieominaisuuksia silmällä pitäen, käyttäjä voi pyytää laskentataulukon uudelleenlaskentaa tai useiden asiakirjojen yhdistämistä ja samanaikaisesti jatkaa taulukon täyttämistä tai avata seuraavan asiakirjan muokkausta varten.

WINDOWS Task Manager

Tehtävienhallinta näyttää tietoja ohjelmista ja prosessit suorittaa tietokoneella. Siellä voit myös tarkastella yleisimmin käytettyjä prosessien suorituskykymittareita.

Tehtävienhallinta näyttää tietokoneen suorituskyvyn tärkeimmät indikaattorit. Käynnissä olevien ohjelmien kohdalla voit tarkastella niiden tilaa ja lopettaa ohjelmat, jotka ovat lakanneet vastaamasta. Voit tarkastella käynnissä olevien prosessien toimintaa jopa 15 parametrin avulla sekä kaavioita ja tietoja suorittimen ja muistin käytöstä.

Lisäksi, jos olet yhteydessä verkkoon, voit tarkastella verkon tilaa ja suorituskykyparametreja. Jos tietokoneeseesi on kytketty useita käyttäjiä, voit nähdä heidän nimensä, heidän suorittamansa tehtävät ja lähettää heille viestin.

Välilehdellä Prosessit näyttää tietoja tietokoneessa käynnissä olevista prosesseista: tiedot prosessorin ja muistin käytöstä, prosessilaskuri ja joitain muita parametreja:

Suorituskyky-välilehdellä näytetään tietoja kuvaajalaskimesta ja säikeistä, muistiparametreista:

Tarvitaan sisään lankojen synkronointi esiintyy vain moniohjelmakäyttöjärjestelmässä ja liittyy laitteiston ja laitteiden yhteiskäyttöön tietolähteitä tietokone. Synkronointi on tarpeen kilpailujen (katso alla) ja lukkiutumien välttämiseksi, kun vaihdetaan tietoja säikeiden välillä, jaetaan tietoja sekä käytettäessä prosessoria ja I/O-laitteita.

Säikeen synkronointi ja prosessit koostuvat niiden nopeuksien koordinoinnista keskeyttämällä virtaus tietyn tapahtuman tapahtumiseen ja sen myöhempään aktivointiin tämän tapahtuman tapahtuessa.

Synkronointiongelmien laiminlyönti monisäikeisessä järjestelmässä voi johtaa väärä päätös tehtäviä tai jopa järjestelmän kaatumista.

Esimerkki . Tehtävä ylläpitää asiakastietokantaa tietylle yritykselle.

Jokaiselle asiakkaalle annetaan erillinen sisäänkäynti tietokannassa, joka sisältää Tilaus- ja Maksukentät. Tietokantaa ylläpitävä ohjelma on suunniteltu yhdeksi prosessiksi, jossa on useita säikeitä, mukaan lukien:

• Lanka A, joka syöttää tietokantaan tiedot asiakkailta saaduista tilauksista.
• Lanka B, joka tallentaa tietokantaan tiedot asiakkaiden laskujen maksuista.

Molemmat säikeet toimivat yhdessä yhteisessä tietokantatiedostossa käyttämällä samantyyppisiä algoritmeja:

1. Lue tietue tietyllä tunnisteella tietokantatiedostosta asiakkaan puskuriin.
2. Syötä uusi arvo Tilaus (virta A) tai maksu (virta B) -kenttään.
3. Palauta muokattu tietue tietokantatiedostoon.

Merkitään vaiheet 1-3 virtaukselle A A1-A3 ja virtaukselle B B1-B3. Oletetaan, että säie A päivittää jossain vaiheessa asiakasta N käsittelevän tietueen Tilaus-kentän. Tätä varten se lukee tämän tietueen puskuriinsa (vaihe A1), muuttaa tilauskentän arvoa (vaihe A2), mutta ei tee tätä. heillä on aikaa lisätä tietue tietokantaan, koska sen suoritus keskeytyy esimerkiksi aikaviipaleen vanhenemisen vuoksi.

Oletetaan, että säiettä B piti syöttää myös samaa asiakasta N koskevat maksutiedot. Kun säikeen B vuoro tulee, se onnistuu lukemaan merkinnän puskuriinsa (vaihe B1) ja päivittämään kentän Maksu(vaihe B2) ja keskeytyy sitten. Huomaa, että virran B puskurissa on tietue asiakkaasta N, jossa kenttä Tilaus sillä on sama, muuttumaton merkitys.

Tärkeä käsite prosessin synkronointi on ohjelman "kriittisen osan" käsite. Kriittinen jakso on ohjelman osa, jossa jaettua dataa käytetään. Kilpailuolosuhteiden vaikutuksen resurssiin eliminoimiseksi on varmistettava, että kyseiseen resurssiin liittyvässä kriittisessä osiossa on milloin tahansa enintään yksi prosessi. Tätä tekniikkaa kutsutaan vastavuoroiseksi poissulkemiseksi.

Yksinkertaisin tapa pakottaa vastavuoroinen poissulkeminen on sallia kriittisen osan prosessin poistaa kaikki keskeytykset käytöstä. Tämä menetelmä ei kuitenkaan sovellu, koska on vaarallista luottaa käyttäjän prosessiin ohjaamaan järjestelmää; se voi käyttää prosessoria pitkään, ja jos prosessi kaatuu kriittisellä alueella, koko järjestelmä kaatuu, koska keskeytykset eivät ole koskaan käytössä.

Toinen tapa on käyttää estomuuttujia. Jokaiseen jaettuun resurssiin on liitetty binäärimuuttuja, joka saa arvon 1, jos resurssi on vapaa (eli mikään prosessi ei ole tällä hetkellä prosessiin liittyvässä kriittisessä osassa) ja arvon 0, jos resurssi on varattu. Alla olevassa kuvassa näkyy fragmentti prosessialgoritmista, joka käyttää estomuuttujaa F(D) toteuttamaan jaettuun resurssiin D pääsyn vastavuoroisen poissulkemisen. Ennen kriittiseen osaan siirtymistä prosessi tarkistaa, onko resurssi D vapaa. Jos se on varattu, niin tarkistus toistetaan syklisesti, jos se on vapaa, niin muuttujan F(D) arvoksi asetetaan 0 ja prosessi siirtyy kriittiseen osioon. Kun prosessi on suorittanut kaikki toiminnot jaetun resurssin D kanssa, muuttujan F(D) arvoksi asetetaan jälleen 1.

Jos kaikki prosessit on kirjoitettu yllä olevien käytäntöjen mukaisesti, molemminpuolinen poissulkeminen on taattu. On huomattava, että estomuuttujan tarkistuksen ja asettamisen on oltava jakamaton. Tämä selitetään seuraavasti. Oletetaan, että muuttujan tarkistuksen tuloksena prosessi totesi, että resurssi oli vapaa, mutta heti sen jälkeen, ilman aikaa asettaa muuttujaa arvoon 0, se keskeytettiin. Kun se oli keskeytettynä, toinen prosessi valtasi resurssin, siirtyi sen kriittiseen osioon, mutta myös keskeytettiin ilman, että työskentely jaetun resurssin kanssa oli valmis. Kun ohjaus palautettiin ensimmäiseen prosessiin, se, katsoen resurssit vapaaksi, asetti varattu-merkin ja aloitti kriittisen osuutensa suorittamisen. Siten molemminpuolisen poissulkemisen periaatetta rikottiin, mikä voi mahdollisesti johtaa ei-toivottuihin seurauksiin. Tällaisten tilanteiden välttämiseksi on suositeltavaa, että koneen komentojärjestelmässä on yksi "check-install" -komento tai se toteutetaan järjestelmä tarkoittaa asianmukaiset ohjelmistoprimitiivit, jotka estävät keskeytykset koko varmennus- ja asennustoiminnan ajan.

Kriittisten osien toteuttamisella estomuuttujien avulla on merkittävä haitta: kun yksi prosessi on kriittisessä osassa, toinen prosessi, joka vaatii samaa resurssia, suorittaa rutiinitoiminnot pollaamalla estomuuttujaa, tuhlaamalla prosessorin aikaa. Tällaisten tilanteiden eliminoimiseksi voidaan käyttää ns. tapahtumalaitteistoa. Tällä työkalulla voidaan ratkaista paitsi keskinäisiä poissulkemisongelmia, myös yleisempiä prosessin synkronointiongelmia. Eri käyttöjärjestelmissä tapahtumalaitteisto on toteutettu omalla tavallaan, mutta joka tapauksessa käytetään samankaltaisia ​​järjestelmätoimintoja, joita kutsutaan perinteisesti WAIT(x) ja POST(x), missä x on joidenkin toimintojen tunniste. tapahtuma.

Jos resurssi on varattu, prosessi ei suorita syklistä kyselyä, vaan kutsuu WAIT(D)-järjestelmäfunktiota, jossa D tarkoittaa tapahtumaa, että resurssi D vapautuu. WAIT(D)-funktio asettaa aktiivisen prosessin ODOTA-tilaan ja tekee kuvauksensa merkinnän, että prosessi odottaa tapahtumaa D. Resurssia D parhaillaan käyttävä prosessi suorittaa kriittisestä osiosta poistuttuaan POST(D) -järjestelmätoiminnon, jonka seurauksena käyttöjärjestelmä skannaa odottavien prosessien jonoon ja asettaa tapahtumaa D odottavan prosessin READY - tilaan .

Dijkstra ehdotti yleistä prosessien synkronointimenetelmää, joka esitteli kaksi uutta primitiiviä. Abstraktissa muodossa nämä primitiivit, joita merkitään P ja V, toimivat ei-negatiivisilla kokonaislukumuuttujilla ns. semaforit. Olkoon S sellainen semafori. Toiminnot määritellään seuraavasti:

V(S): muuttuja S kasvaa yhdellä yhdellä jakamattomalla toimella; hakua, lisäämistä ja tallennusta ei voi keskeyttää, eivätkä muut prosessit pääse S:ään tämän toiminnon aikana.

P(S): Pienentää S:tä yhdellä, jos mahdollista. Jos S=0, niin S:tä on mahdotonta pienentää ja pysyä ei-negatiivisten kokonaislukuarvojen alueella, jolloin P-operaatiota kutsuva prosessi odottaa, kunnes tämä pieneneminen tulee mahdolliseksi. Onnistunut tarkistaminen ja pienentäminen on myös jakamaton toimenpide.

Erikoistapauksessa, jossa semafori S voi ottaa vain arvot 0 ja 1, se muuttuu estäväksi muuttujaksi. P-operaatiolla on mahdollisuus saattaa sitä suorittava prosessi odotustilaan, kun taas V-operaatio voi joissain olosuhteissa aktivoida toisen prosessin, jonka P-toiminto keskeytti.

Prosessin umpikuja

Järjestettäessä useiden prosessien rinnakkaissuoritus, yksi käyttöjärjestelmän päätehtävistä on resurssien oikea jakaminen käynnissä olevien prosessien välillä ja prosesseille tarjoaminen keskinäisen synkronoinnin ja tiedonvaihdon keinoin.

Prosesseja suoritettaessa rinnakkain voi syntyä tilanteita, joissa kaksi tai useampi prosessi on koko ajan estettynä. Yksinkertaisin tapaus on, kun kumpikin kahdesta prosessista odottaa toisen prosessin käyttämää resurssia. Tämän odotuksen vuoksi kumpikaan prosessi ei voi jatkaa suorittamista ja lopulta vapauttaa toisen prosessin tarvitsemaa resurssia. Tätä umpikujaa kutsutaan umpikuja(kuollut lukko) umpikuja, napsauttaa tai umpikuja.

Moniajojärjestelmässä prosessin sanotaan olevan umpikujassa, jos se odottaa tapahtumaa, jota ei koskaan tapahdu.

Umpikujatilanteet on erotettava toisistaan yksinkertaiset jonot, vaikka molemmat tapahtuvat, kun resursseja jaetaan, ja ne näyttävät ulkonäöltään samanlaisilta: prosessi keskeytetään ja odottaa resurssin vapautumista. Jono on kuitenkin normaali, ja se on luontainen merkki korkeasta resurssien käytöstä, kun pyynnöt saapuvat satunnaisesti. Se tapahtuu, kun resurssi ei ole tällä hetkellä saatavilla, mutta jonkin ajan kuluttua se vapautetaan ja prosessi jatkaa suoritustaan. Umpikuja on jokseenkin ratkaisematon tilanne.

Lukitusongelma sisältää seuraavat tehtävät:

1. estämään lukkiutumia.
2. umpikujan tunnistus.
3. järjestelmän palauttaminen umpikujaan.

Lukitukset voidaan estää ohjelmien kirjoitusvaiheessa, eli ohjelmat on kirjoitettava niin, ettei lukkiutumista voi tapahtua millään prosessien keskinäisten nopeuksien suhteen. Joten jos edellisessä esimerkissä prosessi A ja prosessi B pyysivät resursseja samassa järjestyksessä, lukkiutuminen olisi periaatteessa mahdotonta. Toista tapaa estää lukkiutumista kutsutaan dynaamiseksi ja siihen liittyy tiettyjen sääntöjen käyttäminen resurssien osoittamisessa prosesseille, esimerkiksi resurssit voidaan allokoida tietyssä järjestyksessä, joka on yhteinen kaikille prosesseille.

Joissakin tapauksissa, kun lukkiutuminen tapahtuu useiden prosessien kesken, jotka käyttävät monia resursseja, umpikujan tunnistaminen on ei-triviaali tehtävä. On olemassa muodollisia, ohjelmistolla toteutettuja menetelmiä umpikujien tunnistamiseen, jotka perustuvat resurssien allokointitaulukoiden ja varattujen resurssien kyselytaulukoiden ylläpitoon. Näiden taulukoiden analysoinnin avulla voit havaita umpikuja.

Jos lukkiutumistilanne tapahtuu, kaikkia estettyjä prosesseja ei tarvitse poistaa suorituksesta. Voit poistaa vain osan niistä, mikä vapauttaa muiden prosessien odottamia resursseja, voit palauttaa joitain prosesseja swap-alueelle, voit "palauttaa" joitain prosesseja ns. tarkistuspisteeseen, joka tallentaa kaikki palauttamiseen tarvittavat tiedot. ohjelman suoritus alkaen Tämä paikka. Tarkistuspisteet sijoitetaan ohjelmaan paikkoihin, joiden jälkeen voi tapahtua umpikuja.