SISTEMAS DE TIEMPO REAL
Segunda Parte - LA ASIGNACION DE PRIORIDADES DENTRO DE UN ESQUEMA PEEMPTIVO
Alejandro L. Veiga
Como ya fue mencionado anteriormente, en sistemas de tiempo real es deseable una estrategia preemptiva basada en prioridades. Pero, suponiendo que debe garantizarse el cumplimiento de los requerimientos de tiempo de un cierto grupo de tareas, cómo deben ser asignadas las prioridades a las diferentes tareas para que se cumplan completamente los objetivos?
Hasta ahora se ha mencionado que a las diferentes tareas pueden asignársele diferentes prioridades, dentro de un esquema preemptivo, pero no se ha hecho referencia acerca de qué técnica utilizar para decidir qué prioridad asignar a cada tarea, para que se cumplan los requerimientos de todas ellas. El esquema preemptivo no garantiza el cumplimiento de los objetivos; es solamente el entorno más eficiente para la implementación. Algunos problemas de scheduling son irresolubles, y algunos otros tendrán solución solamente con una asignación específica de prioridades.
En algunos casos, la solución al problema de scheduling es simple. Por ejemplo, si sólo una de las tareas es crítica para el sistema, se le asigna a ésta la mayor prioridad y a las demás una prioridad menor. Simple, pero que sucede si existen varias tareas que son críticas? Cómo se diferencia entre las tareas que deben tener la mayor prioridad y las que deben tener la menor? Es necesario alterar las prioridades dinámicamente para satisfacer los requerimientos de tiempo de la aplicación?
Existe actualmente un intenso debate (mayormente académico) acerca de qué algoritmo de scheduling es el más apropiado para sistemas de tiempo real. Mientras tanto, en el campo de aplicación, existe un grupo de técnicas de análisis y diseño que están siendo utilizadas. Algunas de ellas se presentarán a continuación.
Análisis rate-monotonic
Para tareas periódicas con requerimientos estrictos, se presenta a continuación una primera aproximación. Utilizando el análisis rate-monotonic, es simple dilucidar qué prioridad debe asignarse a cada proceso, y analizar si dichas tareas alcanzarán a satisfacer los requerimientos de tiempo.
Para que pueda aplicarse este tipo de análisis, deben cumplirse algunas otras condiciones, además de que las tareas sean periódicas. Se supone también que el tiempo límite para la ejecución de cada tarea es igual a su período, y que el momento de ejecución de cada tarea es al comienzo de éste. Esto significa que cada cierto intervalo de tiempo se ejecuta la tarea, y debe terminarse antes de que llegue el nuevo intervalo. Esto no siempre es cierto, y puede ser que la tarea tenga requerimientos más estrictos.
Se supone, además, que las tareas son independientes una de la otra, que el tiempo consumido en la toma de decisiones es despreciable y que las tareas no pueden suspenderse a sí mismas. Y, por supuesto, que las tareas tienen tiempo de ejecución acotado.
Dentro de este panorama un tanto ideal, la asignación de prioridades rate-monotonic es simple. Debe conocerse la frecuencia de ejecución de las tareas periódicas de tiempo real. Para tareas asincrónicas puede utilizarse el peor caso de arribo como dicha frecuencia, al solo efecto de la asignación de prioridades. A la tarea de mayor frecuencia se le asigna la mayor prioridad y a la de menor frecuencia la prioridad menor. Las tareas de frecuencia intermedia reciben prioridades intermedias, en función de su frecuencia. No debe asignarse la misma prioridad a dos procesos. Todas las prioridades asignadas a las tareas de tiempo real deben ser mayores que la prioridad de cualquier otra tarea presente que no sea de tiempo real. Si dos tareas tienen frecuencias idénticas, se asignan prioridades indistintamente.
Durante la ejecución, la decisión de qué tarea debe ejecutarse en cada momento también es simple de implementar: la tarea disponible con más alta prioridad es ejecutada.
Pero, lógicamente, la asignación de prioridades no alcanza para garantizar que todas las tareas cumplan sus requerimientos de tiempo (lo que llamaremos factibilidad de la implementación). Para realizar el análisis de factibilidad es necesario saber también cuánto tiempo demora cada tarea en ejecutarse. Como se mencionó anteriormente, este tiempo debe estar acotado, y debe ser conocido.
Conocer el tiempo que demora una tarea en ejecutarse no es fácil, ya que debe tenerse en cuenta que generalmente los diferentes sistemas operativos disponen de caches, que hacen que para ejecutar la tarea una única vez se necesite más tiempo que si se ejecuta cíclicamente. Los diferentes sistemas disponen, en general, de herramientas para la medición del tiempo de ejecución de un grupo de funciones.
Una vez conocida la frecuencia y el tiempo de ejecución de cada tarea, puede realizarse el test de factibilidad, que en el caso del análisis rate-monotonic es muy simple. Si la siguiente condición se cumple, el grupo de tareas cumple los requerimientos de tiempo.
Ec 1
Para cada tarea i, Ci es el tiempo de ejecución y Ti es el período. Nótese que el segundo término es aproximadamente igual al ln 2, lo que equivale a decir que es aproximadamente igual a 0.69.
Por consiguiente, para saber si la implementación de un grupo de tareas (que cumplen los requisitos mencionados) es factible asignando prioridades según el análisis rate-monotonic, solo deben sumarse las relaciones C/T de cada tarea (a esta relación la llamaremos factor de utilización). Si la suma resulta menor que 0.69, la implementación cumplirá los requerimientos de tiempo.
Por ejemplo, sea la siguiente aplicación que consta de cinco tareas, como se muestra en la siguiente tabla. La tarea de interfaz con el usuario U se ejecuta 10 veces por segundo. Dos tareas de tiempo real estrictas A y B se ejecutan a 100Hz. Una tarea de recolección de datos C a 33Hz, y el almacenamiento de datos en disco D a 5Hz. La asignación de prioridades rate-monotonic asigna las más altas prioridades a las tareas A y B, por ejemplo 90 y 100. C es la frecuencia que sigue, por lo tanto se le puede asignar 80. U recibe 70 y finalmente D recibe la prioridad más baja, por ejemplo 60. Utilizar números para las prioridades bastante separados entre sí, sirve para no tener que recalcular todas las prioridades cuando se desea agregar una tarea intermedia.
En la siguiente tabla se presentan las tareas periódicas, junto con su frecuencia y tiempo de ejecución, factor de utilización y prioridad asignada según el método rate-monotonic. Sumando los factores de utilización se obtiene 0.657. Esto indica que utilizando dicha asignación de prioridades, la aplicación cumplirá las especificaciones temporales.
Debe aclararse que esta condición es pesimista, ya que es solo una condición suficiente. Podría existir un grupo de funciones que no cumpla el test y en cambio sí funcione en una implementación real. Lo que siempre es cierto es que si cumple el test, la implementación es factible. Un ejemplo clásico de que no es una condición necesaria es el siguiente grupo de tareas. Una tarea A con período 2 y tiempo de ejecución 1, más una tarea B con período 4 y tiempo de ejecución 1. La asignación de prioridades rate-monotonic indica mayor prioridad para la tarea A y menor para la B. El test no se satisface, ya que 1/2 + 1/4 = 0.75 > 0.69. Sin embargo, sin mucho esfuerzo puede imaginarse una secuencia que demuestra que es implementable.
La demostración del test de factibilidad se basa en el análisis del peor caso. Esto implica que todas las tareas comienzan al mismo tiempo y que, por lo tanto, las tareas de baja prioridad serán retardadas al máximo por las de alta prioridad (instancia crítica). La demostración debe encargarse de probar que la instancia crítica es realmente el peor caso (lo que es bastante complicado) y que todas las tareas cumplen los requisitos de tiempo hasta en el peor caso (tiempo de respuesta de la tarea de prioridad más baja menor que su tiempo límite de ejecución).
A pesar de que este test es solo una condición suficiente, es muy utilizado, aunque más no sea como análisis previo, por su simplicidad. Para el análisis exacto se presenta el método que sigue a continuación.
Análisis exacto
El análisis rate-monotonic es simple, pero pesimista, como se mostró anteriormente. El análisis exacto, introducido por Joseph y Pandya [Buttazzo, 1997], también está basado en el análisis de la instancia crítica. Introduce un test de factibilidad mucho más complejo y difícil de calcular. Se trata de una serie numérica, que si converge es una condición suficiente y necesaria para la implementación.
Análisis EDF
El análisis rate-monotonic tiene como una de las condiciones para las tareas que el tiempo límite para su ejecución sea igual a su período. Esto significa que para ejecutar una tarea de período T, se dispone de un tiempo T. Esto no es muy común en la realidad. Muchas veces es necesario que la tarea sea ejecutada en un tiempo menor, aunque su período sea T. Tal es el caso de una adquisición de datos, en la cual se desea que cada toma de datos se realice en forma precisa, a un ritmo T (frecuencia de muestreo constante).
El análisis EDF (earliest deadline first) hace las mismas suposiciones respecto de las tareas que el análisis rate-monotonic, con la excepción que los deadlines pueden ser menores que los períodos. En este método, la asignación de prioridades es diferente. éstas se asignan dinámicamente en cada momento, tal que la tarea con el deadline más próximo recibe la más alta prioridad. En el momento de la ejecución, la tarea de más alta prioridad es ejecutada, lo que significa que constantemente se ejecuta la tarea con el deadline más cercano.
En este caso, luego de una extensa demostración, el test de factibilidad resulta muy simple. Es condición suficiente y necesaria que se cumpla la siguiente condición.
Ec 2
Esto significa que la asignación de prioridades EDF es óptima: si cualquier algoritmo puede encontrar una secuencia, EDF la encontrará también. Es suficiente que se cumpla que el factor de utilización de la CPU sea menor que uno, lo cual es evidente.
Se presenta a continuación un grupo de tareas que no satisface los deadlines si se utiliza la estrategia RM y sí lo hace con EDF. Sean las siguientes tareas:
T1 con período 3 y tiempo de ejecución 1;
T2 con período 6 y tiempo de ejecución 1;
T3 con período 5 y tiempo de ejecución 1; y
T4 con período 10 y tiempo de ejecución 3.
Intentando una secuencia de ejecución según el método RM, T1 recibe la prioridad más alta, T3 la siguiente, T2 la siguiente, y T4 la más baja. Si se suponen todas disponibles en t=0, luego de ejecutarse T1, T3 y T2, como se muestra a continuación, solo quedan dos rebanadas de tiempo para T4, mientras que necesita 3, y pierde su deadline de 10 (nótese que debido a una ejecución anticipada de la segunda instancia de T2 en t=7, dada por su mayor prioridad, T4 sólo consigue ejecutarse en las rebanadas de tiempo 4, 8 y 11, produciendo la falla de T4 en t=10).
Aplicando una estrategia EDF puede verse cómo la segunda instancia de T2 se retrasa, sin perder su deadline, hasta la rebanada de tiempo 11, permitiendo que T4 se ejecute en las rebanadas 4, 7 y 8. El momento crucial de decisión es t= 7. En ese momento el método RM opta por ejecutar T2 ya que tiene prioridad más alta que T4. En cambio EDF opta por T4, pues su deadline está más próximo.
Debe aclararse que si bien este método resulta más atractivo en lo que se refiere al análisis y la performance, es mucho más complejo en el momento de la implementación. Esto se debe a que las prioridades asignadas a las tareas deben ir modificándose a lo largo del tiempo. Este aspecto implica una mayor sobrecarga para el scheduler y el dispatcher, que deberán ser más elaborados que en el caso anterior. Debe recordarse que el análisis teórico se hace considerando que la sobrecarga al sistema debido al scheduler es despreciable, lo cual puede ser no siempre cierto, y más aun cuanto más complicada es la estrategia de scheduling.
Tareas dependientes. Inversión de prioridades, dead-locks y bloqueo encadenado
Hasta ahora se han presentado diferentes formas de análisis y asignación de prioridades para tareas periódicas e independientes. Esto último significa que si dos tareas comparten un recurso, o deben estar sincronizadas, los análisis anteriores no son aplicables. Pero en aplicaciones reales es siempre necesaria la utilización de semáforos, secciones críticas, etc.
Los tests de factibilidad no pueden utilizarse con tareas dependientes. Y aun peor, si existe al menos un recurso compartido, el problema de encontrar el algoritmo de scheduling se torna NP hard (NP significa No Polinomial), como lo demostraron Garey y Johnson [Buttazzo, 1997]. NP hard implica, básicamente, las siguientes consecuencias:
El análisis teórico es extremadamente complejo. Sin embargo debe tratarse de algún modo, ya que son los verdaderos casos de aplicación. Antes de presentar algunas estrategias utilizadas se presentarán los principales problemas a tener en cuenta. De un análisis de éstos surgen algunas soluciones posibles. Se presentará el primero de ellos utilizando un ejemplo.
Considérese el caso en el que exista un recurso exclusivo (que puede ser accedido por una sola tarea simultáneamente) protegido por un semáforo S, más dos tareas que acceden a este recurso: A con prioridad alta, y Z con prioridad baja.
Supóngase que la tarea Z comienza a ejecutarse y entra en la sección crítica; incrementa el semáforo con P(S) y es aceptado. En ese momento, la tarea A está lista para ejecutar, y como tiene mayor prioridad, desplaza a Z. Cuando A intenta acceder al recurso encuentra el semáforo ocupado y P(S) es negado pues está en poder de Z. La tarea A es puesta en estado de espera. Z continúa ejecutando, y finalmente libera la sección crítica decrementando el semáforo con V(S). En ese momento A está en condiciones de ejecutarse nuevamente pues ahora sí puede acceder al recurso compartido.
En este caso pudo verse que la tarea Z de menor prioridad se ejecutó antes que la tarea A de prioridad mayor. Este fenómeno se denomina inversión de prioridades, y es un aspecto muy importante a tener en cuenta en el diseño de sistemas de tiempo real. Puede ocurrir siempre que dos tareas de diferente prioridad accedan a un mismo recurso.
La situación puede ser aún peor. En el ejemplo anterior se presentó la tarea A como capaz de ser suspendida en el caso de encontrar un recurso ocupado, entregando la CPU a la tarea Z para que continúe su procesamiento y libere el semáforo. Pero supóngase que la tarea A no puede suspenderse y continúa acaparando la CPU hasta que el recurso sea liberado. Esto nunca ocurre, pues la tarea Z está suspendida. Dicha situación se denomina dead-lock y lleva a la paralización total de la aplicación, con las consecuentes catástrofes asociadas.
Además, la inversión puede darse entre más de dos tareas. Supóngase que en el panorama anterior existe otra tarea de prioridad intermedia M, que no accede al recurso compartido. Si una vez que Z entró en la zona crítica es desplazada por M, y ésta es a su vez desplazada por A, ocurre una doble inversión de prioridades. Cuando A es suspendida porque encuentra el recurso ocupado, M retoma la ejecución pues es la de prioridad siguiente. Cuando M termina, Z puede ejecutarse, luego de lo cual libera el semáforo. Es recién en ese momento cuando A (la tarea de mayor prioridad) puede retomar la ejecución: después que M y Z (de prioridad menor) terminaron.
Lo que agrava la situación es que dentro de un sistema operativo existen recursos que se comparten sin el conocimiento del usuario. Por ejemplo, considérese el caso de dos tareas que tienen archivos abiertos. Incluso cuando estos dos archivos no estén relacionados, ambas tareas necesitan acceder a los mismos bloques de directorio para tener acceso a los archivos. Dichos bloques deben ser compartidos. Esta es una fuente de inversión de prioridades sobre la cual no se tiene control.
Estas posibles condiciones de las tareas con recursos compartidos son el factor que hace que el análisis de este tipo de sistemas sea más complicado que para EDF o rate-monotonic.
Existen dos formas de evitar la inversión de prioridades, y ninguna de las dos suena muy atractiva. La primera es analizar la aplicación para determinar en qué momento puede ocurrir una inversión, calcular cuanto tiempo de demora implica ésta y cada cuanto sucede. Este tiempo debe ser considerado en el tiempo de respuesta de cada tarea afectada. El problema es que, además de que pueden existir inversiones ocultas, este cálculo puede tornarse muy complicado para un número grande de tareas.
La segunda forma de evitar la inversión de prioridades es el llamado protocolo de herencia de prioridades (priority inheritance protocol ó PIP), introducido por Sha, Lehozcky y Rajkumar en 1990 [Buttazzo, 1997]. Con la herencia de prioridades se evita la inversión utilizando la siguiente regla: “cuando una tarea de baja prioridad Z está bloqueando a una tarea de prioridad alta A, Z continúa ejecutándose con la prioridad de A; en cuanto Z abandona la zona crítica, A continúa su ejecución“. De esta forma, en el ejemplo anterior, M no podría desplazar a Z. Esta regla puede enunciarse también como sigue: “si una tarea de alta prioridad está bloqueada por una de baja prioridad, evitar que la de baja prioridad sea desplazada“.
Debe aclararse que no es suficiente que esta técnica sea utilizada en la aplicación. Debe estar implementada, además, en el sistema operativo, para evitar complicaciones ocultas como la presentada en el ejemplo de los archivos.
Existe un fenómeno más que debe ser tenido en cuenta en el caso de aplicarse la herencia de prioridades. Se denomina bloqueo encadenado, y se presentará también con un ejemplo.
Sean tres tareas y dos semáforos, tal que: A es una tarea de alta prioridad, M es una tarea de prioridad intermedia, Z es una tarea de baja prioridad, A y Z acceden al semáforo S1 y A y M acceden al semáforo S2.
Inicialmente, ambos semáforos están libres. Considérese la siguiente secuencia de eventos: Z comienza y accede a S1; M comienza, desplaza a Z y accede a S2; A comienza, desplaza a M e intenta acceder a S1; como S1 está bloqueado por Z, Z comienza su ejecución con la prioridad de A, desplazando a M; Z continúa su ejecución hasta que libera el semáforo S1 y se resetea la prioridad de Z; A desplaza a Z y accede a S1; A intenta acceder a S2, que está bloqueado por M; M hereda la prioridad de A y ejecuta hasta que libera S2 y se resetea la prioridad de M; A desplaza a M y accede a S2.
En este ejemplo, la tarea A ha sido demorada nuevamente por dos tareas de prioridad más baja, M y Z. Esta vez fueron necesarios dos semáforos. Este fenómeno es lo que se denomina bloqueo encadenado. Sha, Lehozcky y Rajkumar [Buttazzo, 1997] diseñaron una nueva técnica para combatirlo, llamada protocolo de techo de prioridades (priority ceiling protocol ó PCP).
Esta técnica consiste en no dejar que una tarea de baja prioridad acceda a un semáforo que puede ser accedido por una tarea de alta prioridad. Para ello, al semáforo se le asigna un techo, que es la prioridad de la tarea de mayor prioridad que lo accede. Solo las tareas de prioridad más alta que el techo pueden acceder al semáforo. La regla de ejecución es: “la tarea T puede acceder a un semáforo solo si su prioridad es mayor que los techos de todos los semáforos que están actualmente bloqueados“. De esta forma, los semáforos que pueden ser accedidos por tareas de alta prioridad son entregados de a uno por vez.
En el ejemplo anterior, el techo de S1 y de S2 es la prioridad de A. La secuencia de eventos sería la siguiente: Z comienza y accede a S1; M comienza, desplaza a Z e intenta acceder a S2; el acceso es negado pues M<A; M es bloqueada por Z y Z hereda la prioridad de M; A comienza, desplaza a M e intenta acceder a S1; como S1 está bloqueado por Z, Z comienza su ejecución con la prioridad de A; Z continúa su ejecución hasta que libera el semáforo S1 y se resetea la prioridad de Z; A desplaza a Z y accede a S1; A accede a S2 y finaliza; M puede ahora acceder a S2.
Como puede verse, se evitó con esta técnica el doble bloqueo de la tarea de alta prioridad.
Scheduling de tareas no periódicas
Las técnicas presentadas anteriormente son válidas para el análisis de aplicaciones cuyas tareas son todas periódicas. Como se mencionó, puede considerarse la máxima tasa de arribo de las tareas no periódicas (peor caso) y utilizar este tiempo como su período. Pueden así incluirse en el análisis rate-monotonic o EDF. Si se puede conseguir un algoritmo de scheduling para el peor caso, no hay problema. Pero este análisis es muy pesimista.
Existen diferentes técnicas para la asignación de prioridades y el análisis de factibilidad de tareas no periódicas. Algunas de ellas se presentan a continuación.
Servicios de background
Las tareas aperiódicas se ejecutan cuando no hay tareas periódicas presentes. En este caso no existen garantías para las tareas no periódicas, ya que se ejecutan con el tiempo de CPU que sobra de las tareas periódicas.
Polling server
Esta técnica se utiliza para garantizar que al menos una cierta cantidad de procesamiento sea destinado a las tareas aperiódicas, y fue presentada en 1989 por Lehozcky, Sha, Strosnider y Sprunt [Buttazzo, 1997]. Para ello existe una nueva tarea periódica llamada tarea servidor, que se encarga de ejecutar las tareas aperiódicas lo más rápido posible. Esta tarea tiene asignado un cierto tiempo de ejecución, llamado capacidad del servidor Cs. El servidor tiene asignado también un período de ejecución Ts. Así, la relación Cs/Ts puede incluirse en el análisis de factibilidad. Si no hay tareas aperiódicas pendientes, la tarea servidor no se ejecuta. Una tarea aperiódica que aparece inmediatamente después del comienzo de la tarea servidor, con la CPU libre, debe esperar al próximo período, aunque podría ser ejecutada inmediatamente. Esto se debe a que la tarea servidor no se ejecuta si no hay tareas aperiódicas pendientes cuando arranca. Este es el peor caso, sobre la base del cual se realiza el análisis de performance.
Intercambio de prioridades
La técnica de Priority Exchange, presentada en 1987 por Lehozcky, Sha y Strosnider [Buttazzo, 1997], preserva la capacidad no utilizada por la tarea servidor para el futuro. Para ello la tarea servidor intercambia prioridades con el resto de las tareas. Los mismos autores presentaron también en 1987 su Deferrable Server.
Otras técnicas para el scheduling de tareas no periódicas con prioridades estáticas que pueden mencionarse son Sporadic Server (Sprunt, Sha y Strosnider, 1989) y Slack Stealing (Lehozcky y Ramos-Thuel, 1992) [Buttazzo, 1997].
En 1995, Tia, Liu y Shankar [Buttazzo, 1997] demostraron que con asignación estática de prioridades no existe un algoritmo para minimizar el tiempo de respuesta.
Servidores de prioridades dinámicas
Las técnicas anteriores tienen asignación estática de prioridades a las tareas, tomando como base el rate-monotonic. Pueden mencionarse también otras técnicas que utilizan como base el análisis EDF con prioridades dinámicas. Por ejemplo Dynamic Priority Exchange Server (Spuri y Buttazzo, 1994, 1996), Dynamic Sporadic Server (Spuri y Buttazzo, 1994, 1996) y Earliest Deadline Late Server (Chetto, Chetto, 1989). Uno de los servidores dinámicos más recomendados actualmente por su mejor desempeño es el Total Bandwidth Server (Spuri y Buttazzo, 1994, 1996). Para mayor detalle acerca de estos métodos se recomienda el texto Hard Real-Time Computing Systems, Predictable Scheduling Algorithms and Applications [Butazzo, 1997].
Pre run-time scheduling
Esta técnica es un enfoque diferente al problema de scheduling. La toma de decisiones durante la ejecución, tal cual fue presentada hasta el momento, puede llegar a complicarse bastante en el caso de aplicaciones reales, donde coexiste una mezcla de tareas periódicas, aperiódicas, dependientes e independientes. Como se mencionó anteriormente, las reglas de toma de decisiones en el momento de la ejecución deben mantenerse simples para no sobrecargar al sistema con el scheduling. Esto no siempre es posible.
Existe un punto de vista diferente, que presenta una solución a este problema. Se trata de realizar un análisis más intensivo de las situaciones que pueden presentarse. Este análisis puede ser realizado previo a la ejecución del programa, en el momento del diseño. Si se consideran todas las posibilidades y se resuelven todos los problemas de scheduling con antelación, puede construirse una tabla que reemplace al scheduler. Las decisiones se toman previamente.
Por lo tanto no hay un kernel tal como se presentó anteriormente. Solo es necesario un dispatcher que se encargue de ir ejecutando las tareas en la secuencia precalculada que la tabla indica.
Existen varios métodos para la construcción de dicha tabla, entre los cuales puede mencionarse la utilización de los gráficos de precedencia, junto con procedimientos de evaluación de dichos gráficos. Tal es el caso de las estrategias IDA (Fohler, 1991), Branch-and-bound (Ramamritham, 1991) y Two stage branch-and-bound for pipelining (Fohler y Ramamritham, 1997).
Este método tiene la ventaja de ser capaz de enfrentar situaciones muy complejas, como sistemas no polinomiales y estructuras distribuidas, y la desventaja de ser muy poco flexible e incapaz de manejar situaciones excepcionales. Existen algunas técnicas mixtas, que combinan pre run-time y run-time scheduling. Tal es el caso de Mode changes (Fohler, 1991) y Slot shifting (Fohler, 1994).
Para mayor detalle acerca de estos métodos se recomienda también el texto Hard Real-Time Computing Systems, Predictable Scheduling Algorithms and Applications [Butazzo, 1997].
éste es un campo actual de investigación que se encuentra en evolución permanente y es motivo de múltiples debates académicos. En general, los sistemas reales más complejos (como es el caso de los embedded systems de aplicación en la industria aeronáutica y automotriz) están evolucionando hacia una combinación de dichas técnicas.
BIBLIOGRAFIA
Buttazzo, Giorgio. Hard Real-Time Computing Systems, Predictable Scheduling Algorithms and Applications. Kluwer Academic Publishers. 1997.
Laplante, Philip A. Real-Time Systems Design and Analisis. IEEE Press, 1992.