Què és un bloqueig de memòria?

Històricament, tots els programes d'ordinador es van escriure de manera totalment seqüencial. Això és fàcil de llegir, escriure i entendre. També és senzill d'executar per a un ordinador i requereix un maquinari relativament senzill. Amb aquest paradigma de disseny, les dues úniques maneres d'augmentar el rendiment del sistema són escriure codi més eficient i augmentar la velocitat de la CPU. Pot ser possible augmentar l'eficiència del codi, però generalment és un procés complex amb resultats sovint limitats.

Durant dècades, el rendiment es podria reduir esperant CPU noves i més eficients. Tal com descriu la llei de Moore, les CPU aproximadament el doble de rendiment cada dos o tres anys. Malauradament, la majoria d'aquests guanys de rendiment provenien de l'ús de nodes de fabricació cada cop més petits. La tecnologia moderna ha estat lluitant per reduir la mida del node al ritme històric, gràcies a les dificultats materials que treballen a l'escala dels nanòmetres.

Per evitar-ho, els arquitectes de CPU moderns han optat per afegir diversos nuclis de processador a les CPU. Cada nucli de processador pot actuar de manera independent en una tasca diferent. Tot i que no poden combinar el mateix problema, poden treballar en dos problemes simultàniament. Aquest canvi arquitectònic fonamental proporciona un munt de rendiment addicional, però no beneficia directament els processos individuals, tot i que redueix la contenció pel temps del processador.

Per aprofitar les CPU de diversos nuclis, el codi s'ha d'escriure de manera multifil. Aleshores, cada fil es pot executar simultàniament, augmentant el benefici del rendiment pel nombre de fils disponibles i nuclis de CPU. En fer-ho, però, es troba un nou repte, la "condició de carrera".

Nota: Algunes tasques no poden ser multifils, mentre que d'altres poden ser massivament multifils. Els possibles beneficis de rendiment depenen de la feina que es fa.

Condicions de cursa

El programari multifil pot aprofitar diversos nuclis. Els perills estan a l'aguait en aquestes aigües, preparats per atrapar el programador sense experiència. Es pot produir una condició de carrera quan dos fils diferents interactuen amb el mateix bit de memòria.

Un exemple senzill podrien ser dos fils que intenten comprovar i augmentar una variable simultàniament. Diguem que a=0 . Dos fils diferents fan les seves funcions i, en algun moment, marquen a i l'incrementen en un. En general, espereu que el resultat de dos fils afegint un a zero sigui dos. La majoria de vegades, aquest hauria de ser el cas. Podeu obtenir un resultat diferent si els dos fils passen per aquesta funcionalitat específica en el moment adequat.

En aquest cas, el primer fil llegeix el valor d' un . Abans que el primer fil pugui augmentar el valor d' un , el segon fil el llegeix. Ara el primer fil afegeix un a zero, però el segon fil ja creu que el valor és zero, afegint un a zero. El resultat d'això és que el valor final de a és 1, no 2.

Corrent cap al pitjor escenari

Tot i que l'exemple anterior pot no semblar especialment dolent, pot tenir efectes dramàtics. Què passa si el valor d' a selecciona el mode de funcionament d'una màquina? Què passa si els modes específics de funcionament d'aquesta màquina poden ser perillosos o fins i tot posar en perill la vida?

Les condicions de la cursa tampoc han de ser tan simples. Per exemple, és possible que un fil llegeixi una secció de memòria alhora que un altre fil l'escriu. En aquest cas, el fil de lectura pot obtenir una barreja estranya de dades tant d'abans com de després. Suposem que la comprovació és una simple comprovació veritable/fals.

Si la variable va dir cert al començament de la lectura però estava en procés de sobreescriure's a la paraula fals, el resultat de l'operació de lectura podria ser una cosa així com "trlse". Això no és "cert" o "fals". No ser cap de les dues opcions en una elecció binària gairebé segur que provocaria que l'aplicació es bloquegi. Aquesta corrupció de la memòria pot provocar molts problemes de seguretat, com ara la denegació de servei i l'escalada de privilegis.

Tancament de la carrera

Saber quins fragments de memòria d'un programa es comparteixen entre diferents fils és essencial per evitar una condició de carrera. No cal fer res si una variable només està controlada i accessible per un sol fil. Si dos o més fils poden accedir a una variable, heu d'assegurar-vos que totes les operacions d'aquesta peça de memòria es completin independentment les unes de les altres.

Aquesta independència s'aconsegueix gràcies a un pany. Al codi d'un programa, cal posar un bloqueig quan s'escriu una funció que opera en una peça de memòria compartida. Aquest bloqueig impedeix que altres fils accedeixin a aquesta peça de memòria fins que s'alliberi el bloqueig.

El pany no és la solució més elegant. D'una banda, té sobrecàrregues de memòria. També pot forçar un fil a penjar, esperant que s'alliberi un pany. Depenent de la situació, és possible que el bloqueig no s'alliberi durant molt de temps o que no s'alliberi del tot. En el pitjor dels casos, el desbloqueig d'un bloqueig podria dependre d'alguna cosa que succeeixi en un altre fil bloquejat, que condueixi a un bloqueig.

És fonamental optimitzar l'ús dels panys. Podeu controlar com de granular és el bloqueig. Per exemple, si esteu editant dades d'una taula, podeu bloquejar tota la taula o bloquejar només la fila editada. Bloquejar tota la taula seria un bloqueig de granularitat gruixuda. Redueix al mínim la sobrecàrrega d'implementar massa bloquejos, però augmenta la possibilitat que un altre fil quedi bloquejat pel bloqueig. Bloquejar només la fila seria un bloqueig de granularitat fi. És molt menys probable que interfereixi amb altres fils, però significa que es necessitaran panys trencats, augmentant la sobrecàrrega total.

Conclusió

Un bloqueig de memòria és una eina de codi que s'utilitza per garantir l'atomicitat de les operacions a la memòria en un entorn multiprocés. Si tanqueu un tros de memòria abans d'operar-lo, podeu estar segur que no es pot produir cap comportament inesperat a causa d'una condició de carrera. Els bloquejos de memòria inclouen una sobrecàrrega de memòria, però també poden provocar bloqueig.

El bloqueig és on un altre fil intenta operar amb una pemory bloquejada. El fil queda allà, bloquejat fins que s'allibera el bloqueig. Això pot causar problemes si alliberar el bloqueig requereix un altre fil per fer alguna cosa, ja que es pot bloquejar abans que pugui completar el requisit previ per alliberar el bloqueig que el bloqueja. Els bloquejos de memòria es poden evitar escrivint codis que no bloquegen. Fer-ho, però, pot ser complex i amb menys rendiment que utilitzar bloquejos. No us oblideu de deixar els vostres comentaris a continuació.