Inversión de prioridad: ¡Qué diablos!

Primero pongamos la ‘inversión de prioridad’ en el contexto del panorama general, es decir, de dónde viene esto.

En el sistema operativo, uno de los conceptos importantes es la programación de tareas. Existen varios métodos de programación, como por orden de llegada, turno rotativo, programación basada en prioridades, etc. Cada método de programación tiene sus pros y sus contras. Como habrás adivinado, la inversión de prioridad se incluye en la programación basada en prioridades. Básicamente, es un problema que surge a veces cuando el sistema operativo utiliza la programación basada en prioridades. En la programación basada en prioridades, a las diferentes tareas se les asignan diferentes prioridades para que las tareas de mayor prioridad puedan intervenir en tareas de menor prioridad si es posible. 

Por lo tanto, en la programación basada en prioridades, si se está ejecutando una tarea de menor prioridad (L) y si también se necesita ejecutar una tarea de mayor prioridad (H), la tarea de menor prioridad (L) sería reemplazada por una tarea de mayor prioridad (H) . Ahora, suponga que las tareas de menor y mayor prioridad necesitan compartir un recurso común (por ejemplo, acceso al mismo archivo o dispositivo) para lograr su trabajo respectivo. En este caso, dado que se necesita compartir recursos y sincronizar tareas, se pueden usar varios métodos/técnicas para manejar tales escenarios. Por el bien de nuestro tema sobre la inversión de prioridad, mencionemos un método de sincronización, digamos mutex. Solo para recapitular sobre el mutex, una tarea adquiere mutex antes de ingresar a la sección crítica (CS) y libera mutex después de salir de la sección crítica (CS). Mientras se ejecuta en CS, las tareas acceden a este recurso común. Se pueden consultar más detalles sobre estoaquí _ Ahora, supongamos que tanto L como H comparten una sección crítica (CS) común, es decir, se necesita el mismo mutex para esta CS.

Llegando a nuestra discusión sobre la inversión de prioridad, examinemos algunos escenarios. 
1) L se está ejecutando pero no en CS; H necesita correr; H se adelanta a L; H comienza a correr; H renuncia o libera el control; L se reanuda y comienza a ejecutarse 
2) L se ejecuta en CS; H necesita ejecutarse pero no en CS; H se adelanta a L; H comienza a correr; H renuncia al control; L se reanuda y comienza a correr. 
3) L se ejecuta en CS; H también necesita ejecutarse en CS; H espera a que L salga de CS; L sale de CS; H ingresa a CS y comienza a correr

Tenga en cuenta que los escenarios anteriores no muestran el problema de ninguna inversión de prioridad (ni siquiera el escenario 3). Básicamente, siempre que la tarea de menor prioridad no se ejecute en CS compartido, la tarea de mayor prioridad puede adelantarse. Pero si L se ejecuta en CS compartido y H también necesita ejecutarse en CS, H espera hasta que L sale de CS. La idea es que CS debe ser lo suficientemente pequeño para que H no espere mucho tiempo mientras L estaba en CS. Es por eso que escribir un código CS requiere una cuidadosa consideración. En cualquiera de los escenarios anteriores, la inversión de prioridad (es decir, la inversión de prioridad) no ocurrió porque las tareas se ejecutan según el diseño.

Ahora agreguemos otra tarea de prioridad media, digamos M. Ahora las prioridades de las tareas están en el orden de L < M < H. En nuestro ejemplo, M no comparte la misma Sección crítica (CS). En este caso, la siguiente secuencia de tareas en ejecución daría como resultado un problema de ‘Inversión de prioridad’.

4) L se ejecuta en CS; H también necesita ejecutarse en CS; H espera a que L salga de CS; M interrumpe a L y comienza a correr; M corre hasta el final y cede el control; L se reanuda y comienza a correr hasta el final de CS; H ingresa a CS y comienza a correr. 
Tenga en cuenta que ni L ni H comparten CS con M.

Aquí, podemos ver que la ejecución de M ha retrasado la ejecución de L y H. Hablando con precisión, H tiene mayor prioridad y no comparte CS con M; pero H tuvo que esperar a M. Aquí es donde la programación basada en prioridades no funcionó como se esperaba porque las prioridades de M y H se invirtieron a pesar de no compartir ningún CS. Este problema se llama inversión de prioridad. ¡Esto es lo que diablos era la Inversión Prioritaria! En un sistema con programación basada en prioridades, las tareas de mayor prioridad pueden enfrentar este problema y pueden generar un comportamiento/resultado inesperado. En el sistema operativo de propósito general, puede resultar en un rendimiento más lento. En RTOS, puede dar lugar a resultados más graves. El problema de ‘inversión de prioridad’ más famoso fue lo que sucedió en Mars Pathfinder.

Si tenemos un problema, tiene que haber una solución para esto. También para la inversión de prioridad, existen diferentes soluciones, como la herencia de prioridad, etc. Este será nuestro próximo artículo 🙂

Pero para los pacientes hospitalizados, esto puede ser mencionado por el momento. 

Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.