Hva er en minnelås?

Historisk sett ble alle dataprogrammer skrevet på en fullstendig sekvensiell måte. Dette er enkelt å lese, skrive og forstå. Det er også enkelt for en datamaskin å utføre og krever relativt enkel maskinvare. Med dette designparadigmet er de eneste to måtene å øke systemytelsen på å skrive mer effektiv kode og øke CPU-hastigheten. Det kan være mulig å øke kodeeffektiviteten, men det er generelt en kompleks prosess med ofte begrensede resultater.

I flere tiår kunne ytelsen reduseres ved å vente på nye, mer effektive CPUer. Som beskrevet av Moores lov, dobles CPUer omtrent i ytelse hvert annet til tredje år. Dessverre kom de fleste av disse ytelsesgevinstene fra bruk av stadig mindre produksjonsnoder. Moderne teknologi har slitt med å redusere nodestørrelsen med den historiske hastigheten, takket være materielle vanskeligheter med å jobbe i nanometerskalaen.

For å komme rundt dette har moderne CPU-arkitekter valgt å legge til flere prosessorkjerner til CPUer. Hver prosessorkjerne kan handle uavhengig på en annen oppgave. Selv om de ikke kan kombinere det samme problemet, kan de jobbe med to problemer samtidig. Denne grunnleggende arkitektoniske endringen gir mye ekstra ytelse, men den er ikke direkte til fordel for individuelle prosesser, selv om den reduserer striden om prosessortid.

For å dra nytte av multi-core CPUer, må koden skrives på en flertråds måte. Hver tråd kan deretter kjøres samtidig, og skalere ytelsesfordelen med antall tilgjengelige tråder og CPU-kjerner. Å gjøre dette, støter imidlertid på en ny utfordring, "løpsbetingelsen."

Merk: Noen oppgaver kan ikke være flertrådede, mens andre kan være massivt flertrådede. De mulige ytelsesfordelene avhenger av arbeidet som gjøres.

Løpsforhold

Flertråds programvare kan dra nytte av flere kjerner. Farer lurer i disse farvannene, klare til å fange den uerfarne programmereren. En rasetilstand kan oppstå når to forskjellige tråder samhandler med samme minnebit.

Et enkelt eksempel kan være to tråder som prøver å sjekke og øke en variabel samtidig. La oss si at a=0 . To forskjellige tråder utfører deretter sine funksjoner, og på et tidspunkt sjekker du a og øker den med én. Vanligvis forventer du at resultatet av to tråder som legger en til null blir to. Mesteparten av tiden bør dette være tilfelle. Du kan få et annet resultat hvis begge trådene går gjennom den spesifikke funksjonaliteten til nøyaktig rett tid.

I dette tilfellet leser den første tråden verdien av en . Før den første tråden kan øke verdien til en skjønt, leser den andre tråden den. Nå legger den første tråden én til null, men den andre tråden mener allerede at verdien er null, og legger én til null. Resultatet av dette er at den endelige verdien av a er 1, ikke 2.

Racing til det verste scenariet

Selv om eksemplet ovenfor kanskje ikke høres spesielt dårlig ut, kan det ha dramatiske effekter. Hva om verdien til a velger driftsmodusen til en maskin? Hva om bestemte driftsmåter for den maskinen kan være farlige eller til og med livstruende?

Løpsforholdene trenger heller ikke være så enkle. For eksempel kan det være mulig for en tråd å lese en minnedel samtidig som en annen tråd skriver til den. I dette tilfellet kan lesetråden få en merkelig blanding av data fra både før og etter. La oss si at sjekken er en enkel sann/falsk sjekk.

Hvis variabelen sa sant ved starten av lesingen, men var i ferd med å bli overskrevet til ordet usann, kan resultatet av leseoperasjonen være noe sånt som "trlse." Dette er ikke "sant" eller "usant". Å ikke være noen av de to alternativene i et binært valg vil nesten helt sikkert føre til at applikasjonen krasjer. Denne minnekorrupsjonen kan føre til mange sikkerhetsproblemer, for eksempel tjenestenekt og rettighetseskalering.

Låser løpet ute

Å vite hvilke biter av minne i et program som deles mellom forskjellige tråder er avgjørende for å forhindre en løpstilstand. Ingenting trenger å gjøres hvis en variabel kun er kontrollert og tilgjengelig av en enkelt tråd. Hvis to eller flere tråder har tilgang til en variabel, må du sørge for at alle operasjoner på den minnedelen fullføres uavhengig av hverandre.

Denne uavhengigheten oppnås takket være en lås. I koden til et program må du sette en lås når du skriver en funksjon som opererer på et delt minne. Denne låsen blokkerer andre tråder fra å få tilgang til den delen av minnet til låsen frigjøres.

Låsen er ikke den mest elegante løsningen. For det første har den minnekostnader. Den kan også tvinge en tråd til å henge, mens den venter på at en lås skal frigjøres. Avhengig av situasjonen kan det hende at låsen ikke blir utløst på veldig lenge eller ikke blir utløst i det hele tatt. I verste fall kan opplåsing av en lås avhenge av at noe skjer i en annen blokkert tråd, noe som fører til en vranglås.

Det er viktig å optimalisere bruken av låser. Du kan kontrollere hvor granulær låsen er. For eksempel, hvis du redigerer data i en tabell, kan du låse hele tabellen eller låse bare den redigerte raden. Å låse hele bordet ville være en grov granularitetslås. Det minimerer overhead fra å implementere for mange låser, men øker sjansen for at en annen tråd blir blokkert av låsen. Å låse bare raden ville være en fin granularitetslås. Dette er mye mindre sannsynlig å forstyrre andre tråder, men betyr at det vil være behov for revnelåser, noe som øker den totale overheaden.

Konklusjon

En minnelås er et kodeverktøy som brukes til å sikre atomitet i minnet i et flertrådsmiljø. Ved å låse et stykke minne før du opererer på det, kan du være sikker på at ingen uventet oppførsel kan oppstå på grunn av en rasetilstand. Minnelåser kommer med en minneoverhead, men kan også forårsake blokkering.

Blokkering er der en annen tråd forsøker å operere på en låst pemory. Tråden sitter der, blokkert til låsen frigjøres. Dette kan forårsake problemer hvis frigjøring av låsen krever en annen tråd for å gjøre noe, siden den kan bli blokkert før den kan fullføre forutsetningen for å frigjøre låsen som blokkerer den. Minnelåser kan unngås ved å skrive ikke-blokkerende koder. Å gjøre det kan imidlertid være komplisert og mindre effektivt enn å bruke låser. Ikke glem å legge igjen kommentarene dine nedenfor.