¿Es un bloqueo (roscado) atómico?

Question

Esto puede parecer una pregunta estúpida, pero si uno bloquea un recurso en una aplicación de subprocesos múltiples, entonces la operación que ocurre en el recurso, ¿se hace atómicamente?

I.E .: ¿se puede interrumpir el procesador o puede ocurrir un cambio de contexto mientras ese recurso tiene un bloqueo en él? Si lo hace, entonces nada más puede acceder a este recurso hasta que esté programado de nuevo para finalizar su proceso. Suena como una operación costosa.

Answer 1

El procesador definitivamente puede cambiar a otro hilo, sí. De hecho, en la mayoría de las computadoras modernas puede haber múltiples hilos corriendo simultáneamente de todos modos. El bloqueo solo garantiza que ningún otro hilo pueda adquirir el mismo bloqueo, por lo que puede asegurarse de que una operación en ese recurso sea atómica en términos de ese recurso. El código que usa otros recursos puede operar de manera completamente independiente.

Por lo general, debe bloquear para operaciones cortas siempre que sea posible. También puede elegir la granularidad de los bloqueos ... por ejemplo, si tiene dos variables independientes en un objeto compartido, podría usar dos bloqueos separados para proteger el acceso a esas variables. Eso potencialmente proporcionará una mejor concurrencia, pero al mismo tiempo, más bloqueos significan más complejidad y más posibilidades de estancamiento. Siempre hay un acto de equilibrio cuando se trata de concurrencia.

Answer 2

Tienes razón. Esa es una de las razones por las que es tan importante bloquear durante un corto período de tiempo. Sin embargo, esto no es tan malo como parece, ya que no se programará ningún otro subproceso que esté esperando en el bloqueo hasta que el subproceso que contiene el bloqueo lo libere.

Answer 3

Sí, definitivamente se puede producir un cambio de contexto. Esto es exactamente por qué cuando se accede a un recurso compartido también es importante bloquearlo de otro hilo. Cuando el hilo A tiene el bloqueo, el hilo B no puede acceder al código bloqueado.

Por ejemplo, si dos hilos corren el siguiente código:

1. lock(l); 
2. -- change shared resource S here -- 
3. unlock(l); 

un cambio de contexto puede ocurrir después de la etapa 1, pero el otro hilo no puede mantener el bloqueo en ese momento, y por lo tanto, no puede cambiar el recurso compartido . Si el acceso al recurso compartido en uno de los hilos se realiza sin un bloqueo, ¡pueden pasar cosas malas!

En cuanto al desperdicio, sí, es un método derrochador. Esta es la razón por la cual hay métodos que intentan evitar bloqueos por completo. Estos métodos se llaman lock-free, y algunos de ellos se basan en servicios de bloqueo potentes como CAS (Compare-And-Swap) u otros.

Answer 4

No, no es realmente caro. Normalmente hay solo dos posibilidades:

1) El sistema tiene otras cosas que hacer: En este caso, el sistema todavía está haciendo un trabajo útil con todos los núcleos disponibles.

2) El sistema no tiene nada más que hacer: En este caso, se programará el hilo que contiene el bloqueo. Un sistema sano no dejará un núcleo sin usar mientras haya un hilo listo para ejecutar que no está programado.

Entonces, ¿cómo puede ser costoso? Si el sistema no tiene nada más que hacer que no requiera adquirir ese bloqueo (o no hay suficientes elementos para ocupar todos los núcleos) y el hilo que contiene el bloqueo es no listo para funcionar.Así que ese es el caso que debe evitar, y el cambio de contexto o el problema de prioridad no importa (ya que el hilo estaría listo para ejecutarse).