¿Qué es la inanición?

Question

En sistemas multitarea, algunas condiciones anormales impiden el progreso de la ejecución de procesos o subprocesos. Me referiré a ambos procesos e hilos simplemente como "procesos". Dos de estas condiciones se llaman dead-lock y live-lock.

El primero se refiere a procesos que se bloquean entre sí, impidiendo la ejecución. Este último se refiere a procesos que se impiden mutuamente progresar, pero que en realidad no bloquean la ejecución. Por ejemplo, es posible que continuamente se causen mutuamente deshacer transacciones, y que nunca puedan terminarlas.

Otra condición se conoce como inanición de recursos, en la que uno o más recursos finitos, necesarios para el progreso de los procesos, se han agotado y no se pueden restaurar a menos que los procesos progresen. Este es también un caso especial de Live-Lock.

Me gustaría saber si hay alguna otra definición, particularmente académica, para "inanición" que no se limite a "falta de recursos". Las referencias son especialmente bienvenidas.

Y, no, esto no es tarea. :-)

Answer 1

No diría que la falta de recursos es un caso especial de un bloqueo en tiempo real.Por lo general:

• En un bloqueo en tiempo real, ningún hilo avanza, pero siguen ejecutándose. (En un interbloqueo, ni siquiera continúan ejecutándose)

• Cuando mueren de hambre, algunos subprocesos HACEN progreso y algunos subprocesos no se están ejecutando.

Una buena explicación: http://docs.oracle.com/javase/tutorial/essential/concurrency/starvelive.html. Pero entiendo que la elección de la terminología puede variar.

Cuando se trata de la inanición, la definición que oí es:

Supongamos que es posible especificar una ruta infinita de ejecución (entrelazado) coherente con las hipótesis (semántica de semáforos, comportamiento del programador OS ...) de tal manera que el hilo T se suspende esperando algún recurso y nunca se reanuda, incluso si fue posible infinitamente muchas veces. Entonces T se llama morir de hambre.

Pero la práctica no coincide con eso. Supongamos que dos hilos ejecutan una sección crítica en un ciclo infinito. Su código de sincronización permite que el primer hilo ingrese a la sección crítica una vez por hora. ¿Es inanición? Ambos subprocesos pueden progresar, pero el primero está haciendo su trabajo de forma dolorosamente lenta.

La fuente más simple de inanición son los semáforos débiles. Si está utilizando una primitiva de sincronización (o construye la suya propia) que se comporta de manera similar, se producirá la inanición.

problemas clásicos, donde el hambre es bien conocida:

• de lectores y escritores problema. Es posible sincronizar los hilos de tal manera que (1) los lectores podrán morir de hambre a los escritores (2) los escritores serán capaces de morir de hambre a los lectores (3) no inanición ocurrirán (Ver http://en.wikipedia.org/wiki/Readers-writers_problem)

• filósofos de restauración (http://en.wikipedia.org/wiki/Dining_philosophers_problem)

Para más detalles, yo recomiendo de todo corazón El pequeño libro de semáforos (gratis): http://www.greenteapress.com/semaphores/.

Usted está preguntando si cada inanición es causada por la espera de algún recurso. Yo diría que sí.

Un hilo puede ser suspendido:

(1) en alguna llamada de sistema de bloqueo - en espera en/adquisición de un mutex, semáforos, variables condicional; write(), poll() etc.

(2) en alguna operación sin bloqueo, como la realización de cálculos.

Starving on (1) está muriendo de hambre en los recursos (mutexes, buffer, etc.).

Starving on (2) está muriendo de hambre en la CPU: puede considerarlo como un recurso. Si sucede, el problema es con el programador.

HTH

Answer 2

Trabajo es también un tipo de recurso. Cuando la distribución del trabajo en una configuración productor-consumidor no es justa (o ideal), algunos subprocesos pueden no obtener suficientes elementos de trabajo para mantenerlos ocupados todo el tiempo.

Answer 3

Imagina que estás en una cola para comprar comida en un restaurante, para lo cual las mujeres embarazadas tienen prioridad. Y solo hay un montón de mujeres embarazadas que llegan todo el tiempo.

Pronto se morirá de hambre. ;)

Ahora imagina que eres un proceso de baja prioridad y las mujeres embarazadas son de mayor prioridad. =)

Answer 4

Otra área donde la inanición o "bloqueo indefinido" suele aparecer es cuando se habla de algoritmos de Programación prioritaria. Un algoritmo de programación de prioridad tiene la posibilidad de dejar un proceso de baja prioridad esperando indefinidamente. Un flujo constante de procesos de mayor prioridad puede evitar que un proceso de baja prioridad se ejecute.

En el caso de los planificadores de prioridad, la solución está "envejeciendo". El envejecimiento es la técnica de aumentar gradualmente la prioridad de los procesos que esperan en el sistema durante mucho tiempo.

Answer 5

Inanición es simplemente cuando un proceso o servicio no se está sirviendo, incluso cuando no hay un punto muerto en el sistema.

Este es un ejemplo que acabo de inventar solo con fines aclaratorios.

Imagina un algoritmo que controla el acceso de las computadoras a una WAN o algo así. Este algoritmo podría tener una política que diga "Proporcionar acceso prioritario a aquellas computadoras que usarán menos ancho de banda", que parecerá una política adecuada, pero luego, ¿qué sucede cuando una sola computadora desea acceder a la red para una carga ftp que enviar varios GB a alguna parte Con esta política sola, esa computadora morirá de hambre ya que el algoritmo nunca seleccionará esa computadora, ya que siempre habrá otras computadoras que soliciten un uso de ancho de banda más pequeño.

Eso se llama inanición.

Answer 6

Haga un ejemplo de bloqueo de inanición en java.Se trata de prioridad de subprocesos. No estoy seguro si el ejemplo es bueno, pero puede echar un vistazo here.

Answer 7

Un proceso no obtiene un recurso o recursos por más tiempo. Esto no es un punto muerto, porque uno/s proceso/s se ejecuta sin problema. Envejecimiento se puede utilizar para resolver este problema, se utiliza un factor de envejecimiento para cada solicitud.