Hvad er en hukommelseslås?

Historisk set blev alle computerprogrammer skrevet på en fuldstændig sekventiel måde. Dette er nemt at læse, skrive og forstå. Det er også nemt for en computer at udføre og kræver relativt simpel hardware. Med dette designparadigme er de eneste to måder at øge systemets ydeevne på at skrive mere effektiv kode og øge CPU-hastigheden. Det kan være muligt at øge kodeeffektiviteten, men det er generelt en kompleks proces med ofte begrænsede resultater.

I årtier kunne ydeevnen reduceres ved at vente på nye, mere effektive CPU'er. Som beskrevet af Moores lov fordobles CPU'er nogenlunde i ydeevne hvert andet til tredje år. Desværre kom de fleste af disse præstationsgevinster fra brugen af ​​stadig mindre produktionsnoder. Moderne teknologi har kæmpet for at reducere nodestørrelsen med den historiske hastighed takket være materielle vanskeligheder, der arbejder på skalaen af ​​nanometer.

For at omgå dette har moderne CPU-arkitekter valgt at tilføje flere processorkerner til CPU'er. Hver processorkerne kan agere uafhængigt på en anden opgave. Selvom de ikke kan kombinere det samme problem, kan de arbejde på to problemer samtidigt. Denne grundlæggende arkitektoniske ændring giver masser af ekstra ydeevne, men den gavner ikke direkte individuelle processer, selvom den reducerer striden om processortid.

For at drage fordel af multi-core CPU'er skal kode skrives på en multi-threaded måde. Hver tråd kan derefter køres samtidigt, hvilket skalerer ydeevnefordelen med antallet af tilgængelige tråde og CPU-kerner. At gøre dette løber dog ind i en ny udfordring, "racetilstanden".

Bemærk: Nogle opgaver kan ikke være multi-threaded, mens andre kan være massivt multi-threaded. De mulige præstationsfordele afhænger af det arbejde, der udføres.

Race betingelser

Multi-threaded software kan drage fordel af flere kerner. Farer lurer i disse farvande, klar til at fange den uerfarne programmør. En racetilstand kan opstå, når to forskellige tråde interagerer med den samme hukommelsesbit.

Et simpelt eksempel kunne være to tråde, der forsøger at kontrollere og øge en variabel samtidigt. Lad os sige, at a=0 . To forskellige tråde udfører derefter deres funktioner og kontrollerer på et tidspunkt a og øger den med én. Generelt ville du forvente, at resultatet af to tråde, der tilføjer en til nul, er to. Det meste af tiden burde dette være tilfældet. Du kan få et andet resultat, hvis begge tråde gennemgår den specifikke funktionalitet på præcis det rigtige tidspunkt.

I dette tilfælde læser den første tråd værdien af ​​en . Før den første tråd kan øge værdien af ​​en dog, læser den anden tråd den. Nu tilføjer den første tråd en til nul, men den anden tråd mener allerede, at værdien er nul, og tilføjer en til nul. Resultatet af dette er, at den endelige værdi af a er 1, ikke 2.

Racing til Worst Case Scenario

Selvom eksemplet ovenfor måske ikke lyder særlig dårligt, kan det have dramatiske effekter. Hvad hvis værdien af ​​a vælger en maskines driftsmåde? Hvad hvis specifikke driftsformer for den pågældende maskine kan være farlige eller endda livstruende?

Raceforhold behøver heller ikke at være så simple. For eksempel kan det være muligt for en tråd at læse en hukommelsessektion på samme tid som en anden tråd skriver til den. I dette tilfælde kan læsetråden få en underlig blanding af data fra både før og efter. Lad os sige, at checken er en simpel sand/falsk check.

Hvis variablen sagde sand i starten af ​​læsningen, men var i færd med at blive overskrevet til ordet falsk, kan resultatet af læseoperationen være noget i retning af "trlse". Dette er ikke "sandt" eller "falskt". Ikke at være en af ​​de to muligheder i et binært valg ville næsten helt sikkert resultere i, at applikationen går ned. Denne hukommelseskorruption kan føre til mange sikkerhedsproblemer, såsom lammelsesangreb og eskalering af privilegier.

Låser løbet ude

At vide, hvilke stykker hukommelse i et program, der deles mellem forskellige tråde, er afgørende for at forhindre en racetilstand. Der skal ikke gøres noget, hvis en variabel kun er styret og tilgængelig af en enkelt tråd. Hvis to eller flere tråde kan få adgang til en variabel, skal du sikre, at alle operationer på denne hukommelsesdel udføres uafhængigt af hinanden.

Denne uafhængighed opnås takket være en lås. I koden til et program skal du sætte en lås, når du skriver en funktion, der opererer på et delt stykke hukommelse. Denne lås blokerer andre tråde i at få adgang til det stykke hukommelse, indtil låsen frigives.

Låsen er ikke den mest elegante løsning. For det første har det hukommelsesomkostninger. Den kan også tvinge en tråd til at hænge, ​​mens den venter på, at en lås bliver frigivet. Afhængigt af situationen kan låsen muligvis ikke udløses i meget lang tid eller slet ikke udløses. I det værste tilfælde kan oplåsning af en lås afhænge af, at der sker noget i en anden blokeret tråd, hvilket fører til en dødvande.

Det er vigtigt at optimere brugen af ​​låse. Du kan kontrollere, hvor granulær låsen er. Hvis du f.eks. redigerer data i en tabel, kan du låse hele tabellen eller kun låse den redigerede række. Låsning af hele bordet ville være en grov granularitetslås. Det minimerer omkostningerne ved at implementere for mange låse, men øger chancen for, at en anden tråd bliver blokeret af låsen. At låse kun rækken ville være en fin granularitetslås. Dette er meget mindre tilbøjeligt til at forstyrre andre tråde, men betyder, at der er behov for revnelåse, hvilket øger den samlede overhead.

Konklusion

En hukommelseslås er et kodeværktøj, der bruges til at sikre atomicitet i hukommelsen i et multi-threaded miljø. Ved at låse et stykke hukommelse, før du opererer på det, kan du være sikker på, at der ikke kan opstå nogen uventet adfærd på grund af en racetilstand. Hukommelseslåse kommer med en hukommelsesoverhead, men kan også forårsage blokering.

Blokering er, hvor en anden tråd forsøger at operere på en låst pemory. Tråden sidder der, blokeret indtil låsen udløses. Dette kan forårsage problemer, hvis frigivelse af låsen kræver en anden tråd for at gøre noget, da den kan blive blokeret, før den kan fuldføre forudsætningen for at frigive låsen, der blokerer den. Hukommelseslåse kan undgås ved at skrive ikke-blokerende koder. At gøre det kan dog være komplekst og mindre effektivt end at bruge låse. Glem ikke at efterlade dine kommentarer nedenfor.