Que é un bloqueo de memoria?

Históricamente, todos os programas informáticos foron escritos dunha forma totalmente secuencial. Isto é sinxelo de ler, escribir e comprender. Tamén é sinxelo de executar para un ordenador e require un hardware relativamente sinxelo. Con este paradigma de deseño, as dúas únicas formas de aumentar o rendemento do sistema son escribir código máis eficiente e aumentar a velocidade da CPU. Pode ser posible aumentar a eficiencia do código, pero xeralmente é un proceso complexo con resultados a miúdo limitados.

Durante décadas, o rendemento podería diminuír esperando CPUs novas e máis eficientes. Tal e como describe a lei de Moore, as CPU duplican o seu rendemento cada dous ou tres anos. Desafortunadamente, a maioría destas ganancias de rendemento proviñan do uso de nós de fabricación cada vez máis pequenos. A tecnoloxía moderna estivo loitando por diminuír o tamaño dos nodos ao ritmo histórico, grazas ás dificultades materiais que traballan a escala de nanómetros.

Para evitar isto, os arquitectos de CPU modernos optaron por engadir varios núcleos de procesador ás CPU. Cada núcleo de procesador pode actuar de forma independente nunha tarefa diferente. Aínda que non poden combinar o mesmo problema, poden traballar en dous problemas ao mesmo tempo. Este cambio arquitectónico fundamental proporciona moito rendemento extra, pero non beneficia directamente os procesos individuais, aínda que reduce a disputa polo tempo do procesador.

Para aproveitar as CPUs multinúcleo, o código debe escribirse de forma multiproceso. Cada fío pódese executar simultáneamente, escalando o beneficio do rendemento polo número de fíos dispoñibles e núcleos de CPU. Facer isto, porén, atópase cun novo desafío, a "condición de carreira".

Nota: Algunhas tarefas non poden ser multiprocesos, mentres que outras poden ser masivamente multiprocesos. Os posibles beneficios de rendemento dependen do traballo realizado.

Condicións da carreira

O software multiproceso pode aproveitar varios núcleos. Os perigos axexan nesas augas, preparados para atrapar ao programador inexperto. Unha condición de carreira pode ocorrer cando dous fíos diferentes interactúan co mesmo bit de memoria.

Un exemplo sinxelo podería ser dous fíos que intentan comprobar e incrementar unha variable simultaneamente. Digamos que a=0 . Dous fíos diferentes realizan entón as súas funcións e, nalgún momento, marcan a e increméntano nun. Xeralmente, esperarías que o resultado de dous fíos engadindo un a cero sexa dous. Na maioría das veces, este debería ser o caso. Podes obter un resultado diferente se ambos os fíos pasan por esa función específica no momento preciso.

Neste caso, o primeiro fío le o valor dun . Antes de que o primeiro fío poida incrementar o valor de un , o segundo fío leo. Agora o primeiro fío engade un a cero, pero o segundo xa cre que o valor é cero, engadindo un a cero. O resultado é que o valor final de a é 1, non 2.

Correndo cara ao peor dos casos

Aínda que o exemplo anterior pode non soar especialmente mal, pode ter efectos dramáticos. E se o valor de a selecciona o modo de funcionamento dunha máquina? E se modos específicos de funcionamento desa máquina poden ser perigosos ou mesmo ameazar a vida?

As condicións da carreira tampouco teñen por que ser tan sinxelas. Por exemplo, pode ser posible que un fío lea unha sección de memoria ao mesmo tempo que outro fío está escribindo nela. Neste caso, o fío de lectura pode obter unha mestura estraña dos datos do antes e do despois. Digamos que a verificación é unha simple verificación verdadeiro/falso.

Se a variable dicía verdadeiro ao comezo da lectura pero estaba en proceso de sobrescribirse coa palabra false, o resultado da operación de lectura podería ser algo así como "trlse". Isto non é "verdadeiro" ou "falso". Non ser ningunha das dúas opcións nunha opción binaria case con toda seguridade provocaría que a aplicación fallase. Esta corrupción da memoria pode provocar moitos problemas de seguridade, como a denegación de servizo e a escalada de privilexios.

Pechando a carreira

Saber que bits de memoria nun programa se comparten entre diferentes fíos é esencial para evitar unha condición de carreira. Non hai que facer nada se unha variable só está sempre controlada e accesible por un único fío. Se dous ou máis fíos poden acceder a unha variable, debes asegurarte de que todas as operacións nesa peza de memoria se completan independentemente unhas das outras.

Esta independencia conséguese grazas a un peche. No código dun programa, cómpre poñer un bloqueo ao escribir unha función que opera nunha peza de memoria compartida. Este bloqueo impide que outros fíos accedan a ese anaco de memoria ata que se libere o bloqueo.

O bloqueo non é a solución máis elegante. Por unha banda, ten sobrecargas de memoria. Tamén pode forzar a colgar un fío, á espera de que se libere un bloqueo. Dependendo da situación, é posible que o bloqueo non se libere durante moito tempo ou que non se libere en absoluto. No peor dos casos, desbloquear un bloqueo pode depender de que algo suceda noutro fío bloqueado, o que leva a un punto morto.

É fundamental optimizar o uso das pechaduras. Podes controlar o granular que é o bloqueo. Por exemplo, se estás editando datos nunha táboa, podes bloquear toda a táboa ou bloquear só a fila editada. O bloqueo de toda a mesa sería un bloqueo de granularidade grosa. Minimiza a sobrecarga de implementar demasiados bloqueos pero aumenta a posibilidade de que outro fío se bloquee polo bloqueo. Bloquear só a fila sería un bloqueo de granularidade fino. Isto é moito menos probable que interfira con outros fíos, pero significa que serán necesarios bloqueos rasgados, aumentando a sobrecarga total.

Conclusión

Un bloqueo de memoria é unha ferramenta de código que se usa para garantir a atomicidade das operacións en memoria nun ambiente multiproceso. Ao bloquear unha peza de memoria antes de operar nela, podes estar seguro de que non se pode producir ningún comportamento inesperado por mor dunha condición de carreira. Os bloqueos de memoria veñen cunha sobrecarga de memoria, pero tamén poden provocar o bloqueo.

O bloqueo é onde outro fío intenta operar nunha pemory bloqueada. O fío está alí, bloqueado ata que se solta o bloqueo. Isto pode causar problemas se liberar o bloqueo require que outro fío faga algo, xa que pode bloquearse antes de que poida completar o requisito previo para liberar o bloqueo que o bloquea. Os bloqueos de memoria pódense evitar escribindo códigos que non bloqueen. Facelo, non obstante, pode ser complexo e menos eficaz que utilizar bloqueos. Non esquezas deixar os teus comentarios a continuación.