Wat is een geheugenslot?

Historisch gezien werden alle computerprogramma's op een uiterst sequentiële manier geschreven. Dit is eenvoudig te lezen, schrijven en begrijpen. Het is ook eenvoudig uit te voeren door een computer en vereist relatief eenvoudige hardware. Met dit ontwerpparadigma zijn de enige twee manieren om de systeemprestaties te verbeteren, het schrijven van efficiëntere code en het verhogen van de CPU-snelheid. Het verhogen van de code-efficiëntie is misschien mogelijk, maar het is over het algemeen een complex proces met vaak beperkte resultaten.

Decennia lang konden de prestaties afnemen door te wachten op nieuwe, efficiëntere CPU's. Zoals beschreven door de wet van Moore, verdubbelen CPU's ongeveer elke twee tot drie jaar in prestaties. Helaas kwamen de meeste van deze prestatieverbeteringen voort uit het gebruik van steeds kleinere productieknooppunten. Moderne technologie heeft moeite gehad om de knooppuntgrootte in het historische tempo te verkleinen, dankzij materiële problemen bij het werken op de schaal van nanometers.

Om dit te omzeilen, hebben moderne CPU-architecten ervoor gekozen om meerdere processorkernen aan CPU's toe te voegen. Elke processorkern kan onafhankelijk optreden bij een andere taak. Hoewel ze hetzelfde probleem niet kunnen combineren, kunnen ze tegelijkertijd aan twee problemen werken. Deze fundamentele architecturale verandering zorgt voor veel extra prestaties, maar komt niet direct ten goede aan individuele processen, hoewel het wel de strijd om processortijd vermindert.

Om te profiteren van multi-core CPU's, moet code op een multi-threaded manier worden geschreven. Elke thread kan dan gelijktijdig worden uitgevoerd, waardoor het prestatievoordeel wordt geschaald door het aantal beschikbare threads en CPU-cores. Als je dit doet, stuit je echter op een nieuwe uitdaging, de 'raceconditie'.

Opmerking: sommige taken kunnen niet multi-threaded zijn, terwijl andere wel massaal multi-threaded kunnen zijn. De mogelijke prestatievoordelen zijn afhankelijk van het werk dat wordt gedaan.

Wedstrijdvoorwaarden

Multi-threaded software kan profiteren van meerdere cores. In die wateren liggen gevaren op de loer, klaar om de onervaren programmeur in de val te lokken. Een raceconditie kan optreden wanneer twee verschillende threads met hetzelfde stukje geheugen communiceren.

Een eenvoudig voorbeeld zou kunnen zijn dat twee threads tegelijkertijd een variabele proberen te controleren en te verhogen. Laten we zeggen dat a=0 . Twee verschillende threads voeren dan hun functie uit en controleren op een gegeven moment a en verhogen deze met één. Over het algemeen zou je verwachten dat het resultaat van twee threads die één bij nul optellen twee is. Meestal zou dit het geval moeten zijn. U kunt een ander resultaat krijgen als beide threads precies op het juiste moment door die specifieke functionaliteit gaan.

In dit geval leest de eerste thread de waarde van een . Voordat de eerste thread de waarde van een hoewel kan verhogen, leest de tweede thread deze. Nu voegt de eerste thread één toe aan nul, maar de tweede thread gelooft al dat de waarde nul is, en voegt één toe aan nul. Het resultaat hiervan is dat de uiteindelijke waarde van a 1 is, niet 2.

Racen naar het slechtste scenario

Hoewel het bovenstaande voorbeeld misschien niet zo slecht klinkt, kan het dramatische effecten hebben. Wat als de waarde van a de werkingsmodus van een machine selecteert? Wat als specifieke bedieningsmodi van die machine gevaarlijk of zelfs levensbedreigend kunnen zijn?

Race-omstandigheden hoeven ook niet zo eenvoudig te zijn. Het kan bijvoorbeeld mogelijk zijn dat een thread een geheugensectie leest terwijl een andere thread ernaar schrijft. In dit geval kan de leesthread een rare mix krijgen van de gegevens van zowel ervoor als erna. Laten we zeggen dat de controle een eenvoudige waar/onwaar-controle is.

Als de variabele waar was aan het begin van het lezen, maar werd overschreven naar het woord false, kan het resultaat van de leesbewerking zoiets zijn als 'trlse'. Dit is niet 'waar' of 'onwaar'. Geen van de twee opties zijn in een binaire keuze zou er vrijwel zeker toe leiden dat de applicatie crasht. Deze geheugenbeschadiging kan leiden tot veel beveiligingsproblemen, zoals denial of service en escalatie van bevoegdheden.

De race buitensluiten

Weten welke stukjes geheugen in een programma worden gedeeld tussen verschillende threads, is essentieel om een ​​raceconditie te voorkomen. Er hoeft niets te worden gedaan als een variabele alleen wordt bestuurd en toegankelijk is via een enkele thread. Als twee of meer threads toegang hebben tot een variabele, moet u ervoor zorgen dat alle bewerkingen op dat geheugenstuk onafhankelijk van elkaar worden voltooid.

Deze onafhankelijkheid wordt bereikt dankzij een slot. In de code van een programma moet je een slot plaatsen bij het schrijven van een functie die werkt op een gedeeld stuk geheugen. Dit slot blokkeert andere threads om toegang te krijgen tot dat stuk geheugen totdat het slot wordt vrijgegeven.

Het slot is niet de meest elegante oplossing. Om te beginnen heeft het geheugenoverhead. Het kan ook een draad laten hangen, wachtend op een slot dat wordt vrijgegeven. Afhankelijk van de situatie kan de vergrendeling zeer lang niet of helemaal niet worden vrijgegeven. In het ergste geval kan het ontgrendelen van een slot afhankelijk zijn van iets dat gebeurt in een andere geblokkeerde thread, wat tot een impasse kan leiden.

Het is essentieel om het gebruik van sloten te optimaliseren. U kunt bepalen hoe gedetailleerd het slot is. Als u bijvoorbeeld gegevens in een tabel bewerkt, kunt u de hele tabel of alleen de bewerkte rij vergrendelen. Het vergrendelen van de hele tafel zou een grof granulair slot zijn. Het minimaliseert de overhead van het implementeren van te veel sloten, maar vergroot de kans dat een andere thread wordt geblokkeerd door het slot. Alleen de rij vergrendelen zou een prima granulariteitsvergrendeling zijn. Het is veel minder waarschijnlijk dat dit interfereert met andere threads, maar betekent dat gescheurde sloten nodig zijn, waardoor de totale overhead toeneemt.

Conclusie

Een geheugenvergrendeling is een codetool die wordt gebruikt om atomiciteit in het geheugen te garanderen in een omgeving met meerdere threads. Door een stuk geheugen te vergrendelen voordat u erop werkt, kunt u er zeker van zijn dat er geen onverwacht gedrag kan optreden vanwege een raceconditie. Geheugenvergrendelingen hebben een geheugenoverhead, maar kunnen ook blokkering veroorzaken.

Blokkeren is waar een andere thread probeert te werken op een vergrendelde pemory. De draad zit daar, geblokkeerd totdat de vergrendeling wordt vrijgegeven. Dit kan problemen veroorzaken als voor het ontgrendelen van het slot een andere thread nodig is om iets te doen, omdat het geblokkeerd kan raken voordat het de vereiste kan voltooien om het slot te ontgrendelen. Geheugenvergrendelingen kunnen worden vermeden door niet-blokkerende codes te schrijven. Dit kan echter complex en minder efficiënt zijn dan het gebruik van sloten. Vergeet niet om hieronder uw opmerkingen achter te laten.