Linux Kernel Derecho preferente durante spin_lock y mutex_lock

Question

Cuando un proceso en el espacio del núcleo está sosteniendo un spin_lock, el proceso puede no tener preferencia por alguna de las siguientes condiciones:

1. Cuando el intervalo de tiempo del proceso se agotado
2. Cuando un proceso de alta prioridad se vuelve ejecutable
3. Cuando se produce una interrupción

Sin embargo, el proceso puede producir el procesador si bloquea, dormir s, o explícitamente llame al schedule(). Es mi entendimiento correcto?

Cuando un proceso en el espacio del núcleo está sosteniendo un mutex_lock, puede el proceso de ser substituida debido a las condiciones arriba expuestas como 1, 2 y 3.

Answer 1

Las implementaciones actuales de bloqueos de giro utilizan dos mecanismos completamente separados para asegurar exclusión mutua, una para tratar con la exclusión entre procesadores y otra para tratar con los hilos del procesador local y los manejadores de interrupciones.

• Existe el spin_lock mismo que está solo allí para proporcionar mutex entre dos o más núcleos de procesador. Cualquier procesador que golpee un bloqueo de giro bloqueado está básicamente bloqueado hasta que otro procesador lo libere. Los bloqueos de giro no sirven para nada en los sistemas de procesador único, salvo para aumentar las posibilidades de estancamiento total, por lo que generalmente se eliminan en el momento de compilación del kernel.

• Para proporcionar mutex del procesador local, llamadas spin_lock() preempt_disable() (en sistemas de programación preventiva) para evitar que se ejecute cualquier otro hilo mientras se mantiene el bloqueo; de forma similar, spin_lock_irqsave() también hace el equivalente de local_irq_save() para deshabilitar las interrupciones para evitar que se ejecute cualquier otra cosa en el procesador local.

Como debería ser obvio a partir de las, utilizando bloqueos de giro anteriores pueden atascar toda la máquina, de manera bloqueos de giro sólo debe utilizarse por períodos muy cortos de tiempo y nunca se debe hacer nada que pueda causar un cambio de hora mientras se mantiene una cerradura.

El caso con mutex_lock es totalmente diferente: solo los hilos que intentan acceder al bloqueo se ven afectados y si un hilo toca un mutex bloqueado, se producirá una reprogramación. Por este motivo, mutex_locks no se puede usar en contextos de interrupción (u otros contextos atómicos).