Vad är ett minneslås?

Historiskt sett var alla datorprogram skrivna på ett helt sekventiellt sätt. Detta är enkelt att läsa, skriva och förstå. Det är också enkelt för en dator att köra och kräver relativt enkel hårdvara. Med detta designparadigm är de enda två sätten att öka systemets prestanda att skriva effektivare kod och öka CPU-hastigheten. Det kan vara möjligt att öka kodeffektiviteten, men det är i allmänhet en komplex process med ofta begränsade resultat.

I decennier kunde prestandan minskas genom att vänta på nya, mer effektiva CPU:er. Som beskrivs av Moores lag fördubblar CPU:er ungefär sin prestanda vartannat till vart tredje år. Tyvärr kom de flesta av dessa prestandavinster från att använda allt mindre tillverkningsnoder. Modern teknik har kämpat för att minska nodstorleken i den historiska takten, tack vare materiella svårigheter som fungerar i nanometerskalan.

För att komma runt detta har moderna CPU-arkitekter valt att lägga till flera processorkärnor till CPU:er. Varje processorkärna kan agera oberoende på en annan uppgift. Även om de inte kan kombinera samma problem, kan de arbeta med två frågor samtidigt. Denna grundläggande arkitektoniska förändring ger massor av extra prestanda, men den gynnar inte direkt enskilda processer, även om den minskar konflikten om processortid.

För att dra fördel av flerkärniga processorer måste koden skrivas på ett flertrådigt sätt. Varje tråd kan sedan köras samtidigt, och skala prestandafördelen med antalet tillgängliga trådar och CPU-kärnor. Men att göra detta stöter på en ny utmaning, "rasvillkoret".

Obs: Vissa uppgifter kan inte vara flertrådade, medan andra kan vara massivt flertrådade. De möjliga prestationsfördelarna beror på det arbete som utförs.

Race villkor

Flertrådig programvara kan dra fördel av flera kärnor. Faror lurar i dessa vatten, redo att fånga den oerfarna programmeraren. Ett rastillstånd kan uppstå när två olika trådar interagerar med samma minnesbit.

Ett enkelt exempel kan vara två trådar som försöker kontrollera och öka en variabel samtidigt. Låt oss säga att a=0 . Två olika trådar utför sedan sina funktioner och, vid något tillfälle, kontrollera a och öka den med en. I allmänhet skulle du förvänta dig att resultatet av två trådar som lägger till en till noll blir två. För det mesta borde det vara så. Du kan få ett annat resultat om båda trådarna går igenom den specifika funktionen vid exakt rätt tidpunkt.

I det här fallet läser den första tråden värdet av en . Innan den första tråden kan öka värdet på en men, läser den andra tråden den. Nu lägger den första tråden ett till noll, men den andra tråden tror redan att värdet är noll och lägger till ett till noll. Resultatet av detta är att slutvärdet av a är 1, inte 2.

Racing till det värsta scenariot

Även om exemplet ovan kanske inte låter särskilt dåligt, kan det ha dramatiska effekter. Vad händer om värdet på a väljer driftsättet för en maskin? Vad händer om specifika driftssätt för den maskinen kan vara farliga eller till och med livshotande?

Tävlingsförhållandena behöver inte heller vara så enkla. Det kan till exempel vara möjligt för en tråd att läsa ett minnesavsnitt samtidigt som en annan tråd skriver till den. I det här fallet kan lästråden få en konstig blandning av data från både före och efter. Låt oss säga att checken är en enkel sann/falsk kontroll.

Om variabeln sa sant i början av läsningen men höll på att skrivas över till ordet falskt, kan resultatet av läsoperationen bli något i stil med "trlse". Detta är inte "sant" eller "falskt". Att inte vara något av de två alternativen i ett binärt val skulle nästan säkert resultera i att applikationen kraschar. Denna minneskorruption kan leda till många säkerhetsproblem, till exempel överbelastning av tjänster och eskalering av rättigheter.

Låser ut loppet

Att veta vilka bitar av minne i ett program som delas mellan olika trådar är viktigt för att förhindra ett racetillstånd. Ingenting behöver göras om en variabel någonsin endast kontrolleras och är tillgänglig av en enda tråd. Om två eller flera trådar kan komma åt en variabel måste du se till att alla operationer på den minnesbiten slutförs oberoende av varandra.

Denna självständighet uppnås tack vare ett lås. I koden för ett program måste du sätta ett lås när du skriver en funktion som fungerar på ett delat minne. Detta lås blockerar andra trådar från att komma åt det minnet tills låset släpps.

Låset är inte den mest eleganta lösningen. För det första har det minneskostnader. Det kan också tvinga en tråd att hänga i väntan på att ett lås ska släppas. Beroende på situationen kan det hända att låset inte släpps på mycket länge eller inte alls. I ett värsta scenario kan upplåsning av ett lås bero på att något händer i en annan blockerad tråd, vilket leder till ett dödläge.

Det är viktigt att optimera användningen av lås. Du kan styra hur granulärt låset är. Om du till exempel redigerar data i en tabell kan du låsa hela tabellen eller låsa bara den redigerade raden. Att låsa hela bordet skulle vara ett grovt granularitetslås. Det minimerar omkostnaderna från att implementera för många lås men ökar chansen att en annan tråd blockeras av låset. Att bara låsa raden skulle vara ett fint granularitetslås. Detta är mycket mindre sannolikt att störa andra trådar, men betyder att slitna lås kommer att behövas, vilket ökar den totala overheaden.

Slutsats

Ett minneslås är ett kodverktyg som används för att säkerställa atomicitet i minnet i en flertrådig miljö. Genom att låsa en bit minne innan du opererar på den kan du vara säker på att inget oväntat beteende kan inträffa på grund av ett racetillstånd. Minneslås kommer med minneskostnader men kan också orsaka blockering.

Blockering är där en annan tråd försöker operera en låst kropp. Tråden sitter där, blockerad tills låset släpps. Detta kan orsaka problem om frigörandet av låset kräver en annan tråd för att göra något, eftersom den kan blockeras innan den kan fullgöra förutsättningen för att släppa låset som blockerar det. Minneslås kan undvikas genom att skriva icke-blockerande koder. Att göra det kan dock vara komplicerat och mindre effektivt än att använda lås. Glöm inte att lämna dina kommentarer nedan.