Hvað er minnislás?

Sögulega séð voru öll tölvuforrit skrifuð í algjörlega röð. Þetta er einfalt að lesa, skrifa og skilja. Það er líka einfalt fyrir tölvu að framkvæma og krefst tiltölulega einfalds vélbúnaðar. Með þessari hönnunarmynd eru einu tvær leiðirnar til að auka afköst kerfisins að skrifa skilvirkari kóða og auka CPU hraða. Það getur verið mögulegt að auka skilvirkni kóðans, en það er yfirleitt flókið ferli með oft takmarkaðan árangur.

Í áratugi gæti afköst minnkað með því að bíða eftir nýjum, skilvirkari örgjörva. Eins og lýst er í lögum Moore tvöfaldast örgjörvar um það bil í afköstum á tveggja til þriggja ára fresti. Því miður kom mest af þessum frammistöðuávinningi frá því að nota sífellt smærri framleiðsluhnúta. Nútímatækni hefur átt í erfiðleikum með að minnka hnútstærð á sögulegum hraða, þökk sé efniserfiðleikum sem vinna á mælikvarða nanómetra.

Til að komast í kringum þetta hafa nútíma CPU arkitektar valið að bæta mörgum örgjörva kjarna við örgjörva. Hver örgjörvakjarni getur starfað sjálfstætt við mismunandi verkefni. Þó að þeir geti ekki sameinað sama vandamálið, geta þeir unnið að tveimur málum samtímis. Þessi grundvallarbreyting á byggingarlist veitir mikla auka afköst, en hún gagnast ekki einstökum ferlum beint, þó hún dragi úr deilum um tíma örgjörva.

Til að nýta sér fjölkjarna örgjörva verður kóðann að vera skrifaður á fjölþráða hátt. Síðan er hægt að keyra hvern þráð samtímis og skala frammistöðuávinninginn eftir fjölda tiltækra þráða og örgjörvakjarna. Að gera þetta lendir þó í nýrri áskorun, „keppnisástandinu“.

Athugið: Sum verkefni geta ekki verið margþráð, á meðan önnur geta verið gríðarlega fjölþráð. Mögulegur ávinningur af frammistöðu byggir á vinnunni sem er unnin.

Kappakstursskilyrði

Margþráður hugbúnaður getur nýtt sér marga kjarna. Hættur leynast á þessu vatni, tilbúnar til að fanga óreynda forritarann. Kynþáttur getur komið fram þegar tveir mismunandi þræðir hafa samskipti við sama minnisbitann.

Einfalt dæmi gætu verið tveir þræðir sem reyna að athuga og auka breytu samtímis. Segjum að a=0 . Tveir mismunandi þræðir framkvæma síðan hlutverk sitt og, á einhverjum tímapunkti, athuga a og auka hann um einn. Almennt, þú myndir búast við að niðurstaða tveggja þráða sem bætir einum við núll verði tveir. Oftast ætti þetta að vera raunin. Þú getur fengið aðra niðurstöðu ef báðir þræðir fara í gegnum þessa tilteknu virkni á nákvæmlega réttum tíma.

Í þessu tilviki les fyrsti þráðurinn gildi a . Áður en fyrsti þráðurinn getur aukið gildi þó , les seinni þráðurinn hann. Nú bætir fyrsti þráðurinn einum við núll, en seinni þráðurinn telur nú þegar að gildið sé núll, bætir einum við núll. Niðurstaðan af þessu er að lokagildi a er 1, ekki 2.

Kappakstur á versta tilfelli

Þó að dæmið hér að ofan hljómi kannski ekki sérstaklega illa, getur það haft stórkostleg áhrif. Hvað ef gildi a velur vinnslumáta vélar? Hvað ef tilteknar notkunarmátir þessarar vélar geta verið hættulegar eða jafnvel lífshættulegar?

Kappakstursskilyrði þurfa heldur ekki að vera svona einföld. Til dæmis getur verið mögulegt fyrir einn þráð að lesa minnishluta á sama tíma og annar þráður skrifar á hann. Í þessu tilviki getur lesþráðurinn fengið undarlega blöndu af gögnum bæði fyrir og eftir. Segjum að ávísunin sé einföld satt/ósönn ávísun.

Ef breytan sagði satt í upphafi lestursins en var að skrifa yfir í orðið rangt, gæti niðurstaða lestraraðgerðarinnar verið eitthvað eins og „trlse“. Þetta er ekki „satt“ eða „ósatt“. Að vera ekki annar hvor tveggja valkosta í tvíundarvali myndi næstum örugglega leiða til þess að forritið hrundi. Þessi minnisspilling getur leitt til margra öryggisvandamála, svo sem afneitun á þjónustu og aukningu forréttinda.

Lokun á keppninni

Það er nauðsynlegt að vita hvaða minnisbitum í forriti er deilt á milli mismunandi þráða til að koma í veg fyrir keppnisástand. Ekkert þarf að gera ef breyta er alltaf stjórnað og aðgengileg með einum þræði. Ef tveir eða fleiri þræðir hafa aðgang að breytu, þá verður þú að tryggja að allar aðgerðir á því minnisstykki sé lokið óháð hver öðrum.

Þetta sjálfstæði er náð þökk sé lás. Í kóða forrits þarftu að setja læsingu þegar þú skrifar aðgerð sem starfar á sameiginlegu minni. Þessi læsing hindrar aðra þræði í að fá aðgang að því minni þar til læsingunni er sleppt.

Lásinn er ekki glæsilegasta lausnin. Fyrir það fyrsta hefur það minniskostnað. Það getur líka þvingað þráð til að hanga og bíða eftir að lás losni. Það fer eftir aðstæðum, lásinn gæti ekki verið losaður í mjög langan tíma eða alls ekki losaður. Í versta falli gæti opnun lás verið háð því að eitthvað gerist í öðrum læstum þræði, sem leiðir til stöðvunar.

Nauðsynlegt er að hámarka notkun læsinga. Þú getur stjórnað hversu kornótt læsingin er. Til dæmis, ef þú ert að breyta gögnum í töflu gætirðu læst allri töflunni eða læst bara breyttu línunni. Að læsa öllu borðinu væri grófur kyrningalás. Það lágmarkar kostnaðinn vegna innleiðingar á of mörgum læsingum en eykur líkurnar á því að annar þráður verði lokaður af læsingunni. Að læsa bara röðinni væri fínn kornlæsing. Þetta er mun ólíklegra til að trufla aðra þræði, en þýðir að þörf verður á rifnum læsingum, sem eykur heildarkostnaðinn.

Niðurstaða

Minnislás er kóðatól sem er notað til að tryggja atómvirkni í minnisaðgerðum í fjölþráðu umhverfi. Með því að læsa minnishluta áður en aðgerð er á það geturðu verið viss um að engin óvænt hegðun geti átt sér stað vegna keppnisástands. Minnislásar fylgja minniskostnaður en geta einnig valdið lokun.

Lokun er þar sem annar þráður reynir að gera aðgerð á læstum stofu. Þráðurinn situr þarna, læstur þar til læsingunni er sleppt. Þetta getur valdið vandræðum ef losun læsingarinnar krefst þess að annar þráður geri eitthvað, þar sem hann gæti orðið læstur áður en hann getur lokið forsendu þess að losa læsinguna sem lokar hann. Hægt er að forðast minnislæsingar með því að skrifa kóða sem ekki er læst. Að gera það getur hins vegar verið flókið og minna árangursríkt en að nota læsingar. Ekki gleyma að skilja eftir athugasemdir þínar hér að neðan.