Planificación de Tareas en Sistemas de Tiempo Real: Teoría y Sincronización, Traducciones de Ciencias Aplicadas a la Actividad Profesiona

¡Descarga Planificación de Tareas en Sistemas de Tiempo Real: Teoría y Sincronización y más Traducciones en PDF de Ciencias Aplicadas a la Actividad Profesiona solo en Docsity! 17. ANÁLISIS DE FUNCIONAMIENTO DE DISEÑOS DE SOFTWARE DE TIEMPO REAL El análisis de funcionamiento de diseños de software es particularmente importante para sistemas de tiempo real. Las consecuencias de un sistema de tiempo real de no cumplir sus plazos establecidos pueden ser catastrófica. Por lo tanto, es necesario analizar el funcionamiento de un diseño de software de tiempo real antes de su implementación. Puesto que el análisis de funcionamiento es para un diseño concurrente, puede efectuarse tan pronto como la arquitectura de tareas se ha diseñado, tal como se describe en el Capítulo 13. El análisis cuantitativo del diseño de un sistema de tiempo real permite la detección temprana de problemas potenciales de funcionamiento. El análisis es para el diseño de software concurrente conceptualmente ejecutándose sobre una determinada configuración de hardware con una carga de trabajo externa aplicada a esta. La detección temprana de problemas potenciales de funcionamiento permite diseños de software alternativos y configuraciones de hardware para ser investigados, incluyendo sistemas de un sólo procesador y multiprocesador. En este capítulo se describe el análisis de funcionamiento de los diseños de software mediante la aplicación de la teoría de planificación de tiempo real a los diseños de software. La planificación de tiempo real es un enfoque particularmente apropiado para sistemas de tiempo real rígidos con plazos que deben cumplirse (Sha y Goodenough 1990). Con este enfoque, se analiza el diseño de tiempo real con el objeto de determinar si este puede cumplir sus plazos. En este capítulo se describen dos métodos para analizar el funcionamiento de un diseño. El primer enfoque usa la teoría de planificación de tiempo real y el segundo utiliza el análisis de secuencia de eventos. Entonces se combinan los dos enfoques. Tanto la teoría de planificación de tiempo real como el análisis de secuencia de eventos se aplica a un diseño constituido por un conjunto de tareas concurrentes. La Sección 17.1 proporciona una introducción a la teoría de planificación de tiempo real, en particular, el algoritmo de tasa monotónica y dos de sus teoremas, el teorema del factor de utilización y el teorema de tiempo de finalización. La Sección 17.2 describe cómo la teoría de planificación de tiempo real se puede ampliar para tratar con tareas no-periódicas y sincronización de tareas. La Sección 17.3 describe la teoría de planificación de tiempo real generalizada, que se puede aplicar en casos donde la suposición de tasa monotónica no tiene cabida. La Sección 17.4 describe el análisis de funcionamiento de diseños de software de tiempo real utilizando el análisis de secuencia de eventos. La Sección 17.5 entonces describe cómo la teoría de planificación de tiempo real y el análisis de secuencia de eventos se pueden combinar para analizar el funcionamiento de los diseños de software de tiempo real. La Sección 17.6 describe algoritmos avanzados de planificación de tiempo real, incluyendo la planificación de plazo monotónica, la planificación de prioridad dinámica y la planificación para sistemas multiprocesador. La Sección 17.7 describe el análisis de funcionamiento de los sistemas multiprocesador, incluyendo sistemas multinúcleo. Por último, la Sección 17.8 describe la estimación y medición de los parámetros de funcionamiento. 17.1. Teoría de planificación de tiempo real La teoría de planificación de tiempo real trata asuntos de planificación basados en la prioridad de las tareas concurrentes con plazos rígidos. La teoría trata sobre cómo determinar si un grupo de tareas, cuya utilización individual de la CPU se conoce, cumplirán sus plazos. La teoría supone un algoritmo de planificación apropiativo, tal como se describe en el Capítulo 3. Esta sección se basa en los informes y libro sobre planificación de tiempo real producido en el Instituto de Ingeniería de Software (Sha y Goodenough 1990, SEI 1993), los que pueden consultarse para más información sobre el tema. A medida que la teoría de planificación de tiempo real evolucionaba, esta gradualmente se aplicaba a problemas de planificación más complejos. Los problemas tratados incluyen planificación de tareas periódicas independientes, situaciones de planificación en la cual hay tareas tanto periódicas como no-periódicas (es decir, activadas por eventos y activadas a solicitud) y planificación en los casos donde se requiere de tareas de sincronización. 17.1.1. Planificación de tareas periódicas Inicialmente, los algoritmos de planificación de tiempo real fueron desarrollados para tareas periódicas independientes - es decir, tareas periódicas que no se comunican o sincronizan entre sí (Liu y Layland 1973). Desde entonces, la teoría se ha desarrollado considerablemente por lo que ahora se pueden aplicar a otros problemas prácticos, como se ilustrará en los ejemplos. En este capítulo, es preciso comenzar con la teoría básica de tasa monotónica para tareas periódicas independientes y así poder entender cómo se amplia para tratar con situaciones más complejas. Una tarea periódica tiene un período T (la frecuencia con la que se ejecuta) y un tiempo de ejecución C (el tiempo de CPU requerido durante el período). Su utilización de CPU U es la relación C/T. Una tarea es planificable si se cumplen todos sus plazos, es decir, si la tarea completa su ejecución antes de transcurrido su período. Un grupo de tareas se considera planificable si cada una de las tareas puede cumplir sus plazos. Para un conjunto de tareas periódicas independientes, el algoritmo de tasa monotónica asigna a cada tarea una prioridad fija basada en su período, de manera que cuanto más corto el período, mayor la prioridad. Considere tres tareas ta, tb y tc, con períodos de 10, 20 y 30 respectivamente. La prioridad más alta se da a ta, la tarea con el período más corto; la prioridad media se da a tb; y la prioridad más baja se da a tc, la tarea con el período más largo. En Liu y Layland (1973), se demostró formalmente que, para un conjunto de tareas periódicas e independientes de tiempo real, la asignación de prioridades de tasa monotónica es óptima entre todos los esquemas que asignan prioridades únicas y fijas a tareas individuales, cuando las tareas completan su ejecución antes de sus períodos respectivos. 17.1.2. Teorema del factor de utilización Según la teoría de planificación de tasa monotónica (RMS), se puede demostrar que, para que un grupo de n tareas periódicas independiente siempre cumplan sus plazos, la suma de las relaciones C/T de cada tarea debe estar por debajo de un límite superior de utilización global de la CPU. El teorema del factor de utilización (Liu y Layland 1973) declara que: Teorema del factor de utilización (Teorema 1): Un conjunto de n tareas periódicas independientes planificadas por el algoritmo de tasa monotónica siempre cumplirá sus plazos en todas las fases de la tarea, si: donde Ci y Ti son el tiempo y período de ejecución de la tarea ti respectivamente. El límite superior U(n) converge a 69% (Ln (2)) cuando el número de tareas tiende al infinito. Los factores de utilización de hasta nueve tareas, de acuerdo con el Teorema del Factor de Utilización, se dan en la Tabla 17.1. Esto es una aproximación para el peor escenario y para un grupo de tareas elegidas aleatoriamente, Lehoczky, Sha, y Ding (1989) mostraron que el límite superior probable es 88%. Para tareas con períodos armónicos - es decir, con períodos que son múltiplos uno de los otros - el límite superior incluso es mayor y podría alcanzar el 100% si todas las tareas tienen períodos armónicos. Tabla 17.1. Teorema del factor de utilización. Número de tareas n Factor de utilización U(n) 1 1.000 2 0.828 3 0.779 4 0.756 5 0.743 6 0.734 7 0.728 8 0.724 9 0.720 Infinito Ln (2) = 0.693 El algoritmo de tasa monotónica tiene la ventaja de ser estable en condiciones en las que hay una sobrecarga transitoria. En otras palabras, un subconjunto del número total de tareas – concretamente, aquellas con las prioridades más altas (y, por lo tanto, períodos más cortos) - todavía cumplirán sus plazos Al comienzo del segundo período de la tarea t1, t3 es expropiada por la tarea t1. Después de ejecutarse por 20 ms, t1 completa su ejecución y sede la CPU a la tarea t3 de nuevo. La tarea t3 se ejecuta hasta el final del período T2 (150 ms), que representa el segundo punto de planificación debido al plazo de t2. Como t2 completa su ejecución antes de transcurrido T1 (menor que T2), fácilmente cumple su plazo. En este momento, t3 ha usado 80 ms de los 90 necesarios. Al principio del segundo período de t2, la tarea t3 es expropiada por la tarea t2. Después de ejecutarse por 30 ms, t2 completa su ejecución y cede la CPU a la tarea t3 de nuevo. La tarea t3 se ejecuta por otros 10 ms, momento en el que se acaba el tiempo de CPU de 90 ms, completando así su ejecución antes de su plazo. La Figura 17.1 muestra el tercer punto de planificación, que a su vez es el final del segundo período de t1 (2T1 = 200) y el final del primer período de t3 (T3 = 200). La Figura 17.1 muestra que cada una de las tres tareas completa su ejecución antes del término de su primer período, y así cumplen satisfactoriamente sus plazos. La Figura 17.1 muestra también que la CPU está inactiva por 10 ms antes del comienzo del tercer período de t1 (también el comienzo del segundo período de t3). Debe tenerse en cuenta que se usó un tiempo de CPU total de 190 ms a lo largo del período de 200 ms, lo que resulta una utilización de CPU de 0.95 para el período de 200 ms, aunque la utilización global es de 0.85. Después de un tiempo transcurrido igual al mínimo común múltiplo de los tres períodos (600 ms en este ejemplo) la utilización alcanza el promedio de 0.85. 17.1.6. Formulación matemática del teorema del plazo de ejecución El Teorema del Plazo de Ejecución para un sistema de un sólo procesador se puede expresar matemáticamente en el Teorema 3 (Sha y Goodenough 1990) como sigue: Formulación Matemática del Teorema del Plazo de Ejecución (Teorema 3): Un conjunto de n tareas periódicas independiente planificadas por el algoritmo de tasa monotónica siempre cumplirá sus plazos para todas las fases de las tareas, si y sólo si: donde Cj y Tj son el tiempo y período de ejecución de la tarea tj respectivamente y Ri = {(k, p)|1 ⩽ k ⩽ i, p = 1, …., ⌊Ti/Tk⌋}. En la fórmula, ti denota la tarea a ser controlada, y tk denota cada una de las tareas de mayor prioridad que impactan en el tiempo de finalización de la tarea ti. Para una tarea ti y tarea tk dadas, cada valor de p representa un punto de planificación de la tarea tk. En cada punto de planificación, es necesario considerar el tiempo de CPU Ci de la tarea ti una vez, también el tiempo de CPU usado por las tareas de mayor prioridad. Por lo tanto, se puede determinar si ti completará su ejecución en ese punto de planificación. Considere el Teorema 3 aplicado a las tres tareas, que fueron ilustradas en el diagrama de timing de la Figura 17.1. El diagrama de timing es una representación gráfica de lo que calcula el Teorema 3. Una vez más, se considera el peor escenario cuando las tres tareas están listas para ejecutarse al mismo tiempo. La desigualdad para el primer punto de planificación, T1 = 100, lo da el Teorema 3: Para que esta desigualdad se satisfaga, todas las tres tareas tendrían que completar su ejecución dentro del primer período T1 de la tarea t1. Esto no es el caso, ya que antes de que t3 complete, es expropiado por t1 al comienzo del segundo período de t1. La desigualdad para el segundo punto de planificación, T2 = 150, también lo da el Teorema 3: Para que esta desigualdad se satisfaga, la tarea t1 tendría que completar su ejecución dos veces y las tareas t2 y t3 cada una tendría que completar su ejecución una vez dentro del segundo período T2 de la tarea t2. Esto no es el caso, ya que t3 es expropiada por la tarea t2 al comienzo del segundo período de t2. La desigualdad en el tercer punto de planificación, que es a la vez el final del segundo período de t1 (2T1 = 200) y el final del primer período de t3 (T3 = 200), también lo da el Teorema 3: Esta vez, la desigualdad se satisface y las tres tareas cumplen sus plazos. Siempre y cuando todas las tres tareas cumplan al menos uno de los plazos del punto de planificación, las tareas son planificables. 17.2. Planificación de tiempo real para tareas no-periódicas y sincronización de tareas La teoría de planificación de tiempo real se puede ampliar para tratar con tareas no-periódicas, que no se ejecutan periódicamente, y en situaciones donde se necesita sincronización de tareas, tal como se describe en esta sección. 17.2.1. Planificación de tareas periódicas y no-periódicas Para tratar con tareas no-periódicas también con tareas periódicas, debe ampliarse la teoría de tasa monotónica. Una tarea no-periódica se supone que llegará aleatoriamente y se ejecutará una vez dentro de algún período Ta, que representa el tiempo mínimo entre llegadas del evento que activa a la tarea. El tiempo de CPU Ca usado por la tarea no-periódica para procesar el evento está reservado como un ticket de valor Ca para cada período Ta. Cuando llega el evento, la tarea no-periódica se activa, reclama su ticket y lo consume hasta Ca unidades de tiempo de CPU. Si la tarea no se activa durante el período Ta, el ticket se descarta. Por tanto, en base a estos supuestos, la utilización de CPU de la tarea no-periódica es Ca/Ta. Es más, representa la utilización de CPU para el peor escenario porque generalmente, los tickets reservados no siempre se reclaman. Si existen muchas tareas no-periódicas en la aplicación, se puede usar el algoritmo de servidor esporádico (Sprunt, Lehoczy, y Sha 1989). Desde el punto de vista del análisis de la planificabilidad, una tarea no- periódica (referida como servidor esporádico) es equivalente a una tarea periódica cuyo período es igual al tiempo mínimo entre llegadas de los eventos que activan la tarea periódica. De ahí que Ta, el tiempo mínimo entre llegadas para una tarea no-periódica ta, puede considerarse el período de una tarea periódica equivalente. A cada tarea también se le da una asignación de Ca unidades de tiempo de CPU, que se puede consumir en cualquier momento durante su período equivalente Ta. De esta manera, las tareas no-periódicas pueden ubicarse en diferentes niveles de prioridad de acuerdo a sus períodos equivalentes y tratarse como tareas periódicas. 17.2.2. Planificación con sincronización de tareas La teoría de planificación de tiempo real también se amplia para tratar con la sincronización de tareas. El problema aquí es que una tarea que entra a una sección crítica puede bloquear a otras tareas de mayor prioridad que desean entrar a la sección crítica. El termino inversión de prioridad se usa para referirse al caso donde una tarea de baja prioridad impide que otra tarea de mayor prioridad se ejecute, normalmente mediante la adquisición de un recurso necesitado por el último. La inversión de prioridad no acotada se puede producir porque la tarea de menor prioridad, estando en su sección crítica, puede ser bloqueada por otras tareas con prioridades medias, prolongándose así el retraso total experimentado por la tarea de mayor prioridad. Una solución a este problema es evitar la expropiación de la tarea mientras esté en su sección crítica. Esto es aceptable sólo si la tarea tiene secciones críticas muy cortas. En secciones criticas largas, las tareas con prioridad menores podrían bloquear a las tareas con prioridades mayores que necesitan tener acceso al recurso compartido. El protocolo techo de prioridad (Sha y Goodenough 1990) previene los deadlock mutuos (situaciones sin salida) al proporcionar una inversión de prioridad acotada; es decir, que una tarea de menor prioridad, a lo mucho, puede bloquear a una tarea de mayor prioridad. Aquí sólo se considera el caso más simple, el de una sección critica. Se usan prioridades ajustables para prevenir que tareas de menor prioridad retrasen a tareas de mayor prioridad por un tiempo arbitrariamente largo. Mientras que una tarea de baja prioridad t1 esté en su sección crítica, tareas de mayor prioridad puede llegar a bloquearse porque desean adquirir el mismo recurso. Si eso sucede, la prioridad de t1 se incrementa hasta una prioridad mayor a todas las prioridades de las tareas bloqueadas. El objetivo es acelerar la ejecución de la tarea de menor prioridad de modo que se reduzca el tiempo de bloqueo de las tareas de mayor prioridad. El techo de prioridad P de un semáforo binario S es la prioridad más alta de todas las tareas que pueden adquirir el semáforo. Por lo tanto, una tarea de baja prioridad que adquiere S puede que haya aumentado su prioridad hasta P, dependiendo de las tareas de mayor prioridad que esta bloquea. El otro caso que podría ocurrir es el deadlock, en el cual dos tareas cada una con la necesidad de adquirir dos recursos antes de completar su ejecución. Si cada tarea adquiere un recurso, no serán capaces de completar su ejecucion, ya que cada una estaría esperando que la otra libere su recurso - una situación sin salida (deadlock). El protocolo techo de prioridad soluciona este problema (Sha y Goodenough 1990). El teorema de planificación de tasa monotónica necesita ampliarse para tratar los problemas de inversión de prioridad, tal como se describe en la siguiente sección. 17.3. Teoría de planificación de tiempo real generalizada En los problemas del mundo real, a menudo surgen situaciones en la cual la suposición de tasa monotónica no se mantiene. Hay muchos casos prácticos donde las tareas tienen que ejecutarse con prioridades reales diferentes de sus prioridades de tasa monotónica. Por lo tanto, es necesario ampliar la teoría básica de planificación de tasa monotónica para tratar estos casos. Un caso se da en la sección anterior cuando una tarea de menor prioridad bloquea a tareas de mayor prioridad al entrar en secciones críticas. Un segundo caso sucede a menudo cuando hay tareas no-periódicas. Como se discutió en la Sección 17.2.1, las tareas no-periódicas pueden tratarse como tareas periódicas, si se considera el tiempo entre llegadas para el peor escenario como el período de la tarea periódica equivalente. Siguiendo el algoritmo de planificación de tasa monotónica, si la tarea no-periódica tiene un período mayor al de una tarea periódica, se debe ejecutar con una prioridad menor al de la tarea periódica. Sin embargo, si la tarea no-periódica se conduce por interrupciones, necesitará ejecutarse tan pronto lleguen las interrupciones, incluso si su tiempo entre llegadas para el peor escenario, y de aquí el período equivalente, es mayor al de la tarea periódica. 17.3.1. Inversión de prioridad El termino inversión de prioridad se da a cualquier caso donde una tarea no se puede ejecutar porque está bloqueada por una tarea de menor prioridad. En el caso de la inversión de prioridad de tasa monotónica, el término "prioridad" se refiere a la prioridad de tasa monotónica; es decir, la prioridad asignada a una tarea basada íntegramente en la longitud de su período y no en su importancia relativa. Una tarea puede ser asignada con una prioridad real diferente de la prioridad de tasa monotónica. La inversión de prioridad de tasa monotónica se refiere a que una tarea A es expropiada por una tarea B de mayor prioridad, cuando de hecho la prioridad de tasa monotónica de la tarea B es menor que la de A (es decir, el período de B es mayor que el de A). Esto se ilustra en el siguiente ejemplo de inversión de prioridad de tasa monotónica, donde hay una tarea periódica con período de 25 ms y una tarea conducida por interrupciones con un tiempo entre llegadas para el peor escenario de 50 ms. La tarea periódica tiene mayor prioridad de tasa monotónica porque tiene el período más corto; sin embargo, en la práctica, se prefiere dar a la tarea conducida por interrupciones una prioridad real mayor para que pueda servir a las interrupciones tan pronto lleguen. Siempre que la tarea conducida por interrupciones expropie a la tarea periódica, se considera un caso de inversión de prioridad relativa a la asignación de prioridades de tasa monotónica, ya que, si a la tarea conducida por interrupciones se le hubiera dado su prioridad de tasa monotónica, no habría expropiado a la tarea periódica. Es necesario ampliar la teoría básica de planificación de tasa monotónica para tratar estos casos prácticos de inversión de prioridad de tasa monotónica. Esto se logra mediante la ampliación de los algoritmos básicos que toman en cuenta el efecto del bloqueo de tareas con prioridades menores, así como la expropiación por tareas con prioridades mayores que no cumplan con las prioridades de tasa monotónica (SEI 1993). Dado que la teoría de planificación de tasa monotónica asume prioridades de tasa monotónica, La utilización de CPU global es de 0.42, que está por debajo del factor de utilización para el peor escenario de 0,69. Sin embargo, es necesario investigar cada tarea individualmente ya que no se asignaron prioridades de tasa monotónica. Primero consideremos a la tarea conducida por interrupciones ta. La tarea ta es la tarea de mayor prioridad, que siempre logra la CPU cuando lo necesita. Su utilización es 0,04, así que no tendrá ninguna dificultad para cumplir con su plazo. A continuación, consideremos a la tarea t1, que se ejecuta por 20 ms durante su período T1 de 100 ms. Aplicando el Teorema del Factor de Utilización Generalizado, se necesita tener en cuenta los siguientes cuatro factores: a. Tiempo apropiativo por tareas de mayor prioridad con períodos menores que T1. No existen tareas con períodos menos que T1. b. Tiempo de ejecución C1 para la tarea t1 = 20. Utilización de ejecución = U1 = 20/100 = 0.20. c. Apropiación por tareas de mayor prioridad con períodos más largos. La tarea ta conducida por interrupciones cae dentro de esta categoría. Por tanto, la utilización apropiativa durante el periodo T1 = Ca/T1 = 4/100 = 0.04. d. Tiempo de bloqueo por tareas de menor prioridad. Tanto t2 como t3 potencialmente pueden bloquear t1. En base al algoritmo de techo de prioridad, a lo mucho, una tarea de menor prioridad puede bloquear realmente a t1. El peor escenario es l tarea t3, porque tiene un tiempo de CPU mayor de 30 ms. Por tanto, la utilización de bloqueo durante el periodo T1 = B3/T1 = 30/100 = 0.30. Utilización para el peor escenario = utilización apropiativa + utilización de ejecución + utilización de bloqueo = 0.04 + 0.20 + 0.30 = 0.54 < límite superior teórico para el peor escenario de 0.69. En consecuencia, t1 cumplirá su plazo. Ahora consideremos la tarea t2, que se ejecuta por 15 ms durante su período T2 de 150 ms. Una vez más, aplicando el Teorema del Factor de Utilización Generalizado, se necesita tener en cuenta los siguientes cuatro factores: a. Tiempo apropiativo por tareas de mayor prioridad con períodos menores que T2. Sólo una tarea, t1, tiene un periodo menor a T2. Su utilización apropiativa durante el periodo T2 = U1 = 0.20. b. Tiempo de ejecución C2 para la tarea t2 = 15. Utilización de ejecución = U2 = 15/150 = 0.10. c. Apropiación por tareas de mayor prioridad con períodos más largos. La tarea ta conducida por interrupciones cae dentro de esta categoría. Utilización apropiativa durante el periodo T2 = Ca/T2 = 4/150 = 0.03. Utilización apropiativa total por t1 y ta = 0.20 + 0.03 = 0.23. d. Tiempo de bloqueo por tareas de menor prioridad. La tarea t3 puede bloquear a t2. En el peor escenario, puede bloquear a t2 por su tiempo total de CPU de 30 ms. La utilización de bloqueo durante el periodo T2 = B3/T2 = 30/150 = 0.20. Utilización para el peor escenario = utilización apropiativa + utilización de ejecución + utilización de bloqueo = 0.23 + 0.10 + 0.20 = 0.53 < límite superior teórico para el peor escenario de 0.69. En consecuencia, t2 cumplirá su plazo. Finalmente, consideremos a la tarea t3, que se ejecuta por 30 ms durante su periodo T3 de 300 ms. Una vez más, aplicando el Teorema del Factor de Utilización Generalizado, se necesita tener en cuenta los siguientes cuatro factores: a. Tiempo apropiativo por tareas de mayor prioridad con períodos menores que T3. Todas las tres tareas de mayor prioridad caen en esta categoría, así que la utilización apropiativa total = U1 + U2 + Ua = 0.20 + 0.10 + 0.02 = 0.32. b. Tiempo de ejecución C3 para la tarea t3. Utilización de ejecución = U3 = 30/300 = 0.10. c. Apropiación por tareas de mayor prioridad con períodos más largos. No existen tareas que caigan en esta categoría. d. Tiempo de bloqueo por tareas de menor prioridad. No existen tareas que caigan en esta categoría. Utilización para el peor escenario = utilización apropiativa + utilización de ejecución = 0.32 + 0.10 = 0.42 < límite superior teórico para el peor escenario de 0.69. En consecuencia, t3 cumplirá su plazo. En conclusión, todas las cuatro tareas cumplirán sus plazos. 17.3.6. Ejemplo de aplicación del teorema del plazo de ejecución generalizado Tenga en cuenta cómo se aplica el Teorema del Plazo de Ejecución Generalizado (Sección 17.3.3) al ejemplo de la sección anterior, donde existen dos tareas periódicas (t1 y t3) y dos tareas no-periódicas (t2 y ta). Tres de las cuales (t1, t2 y t3) tienen acceso mutuamente excluyente a una sección crítica. Dado que, una de las tareas no-periódicas, ta, necesita tener una prioridad mayor diferente de su prioridad de tasa monotónica, la asignación de prioridades es, ta con la prioridad más alta, seguida respectivamente por t1, t2 y t3. La ejecución de estas cuatro tareas en un sistema de un sólo procesador se representa en la Figura 17.2, donde se considera el peor escenario de las cuatro tareas cuando están listas para ejecutarse al mismo tiempo. La tarea de mayor prioridad ta se ejecuta primero por 4 ms, seguido por la tarea con la siguiente prioridad más alta t1, por su tiempo de ejecución de 20 ms. Las siguientes dos tareas, t2 y t3, también se ejecuta en orden de prioridad y todas las tareas cumplen sus plazos. En este ejemplo, la exclusión mutua está garantizada por las tareas ejecutándose en secuencia. Figura 17.2. Diagrama de timing para tareas ejecutándose en un sistema de un sólo procesador con exclusión mutua. 17.4. Análisis de funcionamiento usando el análisis de secuencia de eventos Durante la fase de requerimientos del proyecto, se especifican los tiempos de respuesta requeridos del sistema a eventos externos. Después de la estructuración de tareas, se puede hacer un primer intento de asignar tiempos estimados a las tareas concurrentes del sistema. El análisis de secuencia de eventos se usa para determinar la secuencia de tareas que necesitan ejecutarse para servir a un determinado evento externo. La primera tarea en la secuencia de eventos espera por el evento que inicia la secuencia (por ejemplo, un evento externo), mientras que las otras tareas en la secuencia de eventos se ejecutan en secuencia estricta ya que cada tarea se activa por un mensaje enviado por su predecesora. También, si una determinada tarea envía mensajes a más de una tarea en espera, es posible dividir la secuencia de eventos en más de una secuencia de eventos. Se usa un diagrama de timing para representar la secuencia de eventos interna y tareas activadas después de la llegada del evento externo. El enfoque se describe a continuación. Considerar un evento externo; determinar qué tareas de E/S se activan por este evento y luego determinar la secuencia de eventos interna que siguen. Esto requiere la identificación de tareas que se activan y tareas de E/S que generan respuestas del sistema a eventos externos. Estimar el tiempo de CPU para cada tarea. Estimar el overhead de CPU, que consta del overhead de los cambios de contexto y overhead de la comunicación y sincronización entre tareas. También es necesario considerar a cualquier otra tarea(s) que se ejecute durante este período. La suma de los tiempos de CPU de las tareas que participan en la secuencia de eventos, más la de aquellas tareas adicionales que se ejecutan, más el overhead de CPU, debe ser menor o igual al tiempo de respuesta del sistema especificado. Si existe alguna duda sobre los tiempos de CPU de las tareas, asignar el límite superior considerando el peor escenario. Para estimar la utilización de CPU global, es necesario estimar, para un determinado intervalo de tiempo, el tiempo de CPU para cada tarea. Si existe más de una ruta a través de la tarea, estimar el tiempo de CPU para cada ruta. Luego, estimar la frecuencia de activación de las tareas. Para tareas periódicas se calcula fácilmente. Para tareas no-periódicas, considerar tasas de activación promedio y máximas. Multiplicar el tiempo de CPU de cada tarea por su tasa de activación. Sumar todos los tiempos de CPU de las tareas y entonces calcular la utilización de CPU. Un ejemplo de aplicación del enfoque de análisis de secuencia de eventos se da a continuación. Un ejemplo más detallado se da en el Capítulo 18. 17.4.1. Ejemplo del análisis de funcionamiento usando el análisis de secuencia de eventos Como un ejemplo de aplicación del enfoque de análisis de secuencia de eventos, considere cuatro tareas con los mismos tiempos de CPU y periodos de aquellos descritos en la Sección 17.3.5. Sin embargo, esta vez considerar la situación donde tres de estas tareas están involucradas en una secuencia de eventos donde las tareas se ejecutan en el orden t1, t2 y t3, de forma que la tarea t1 despierta por un evento externo y las tareas t2 y t3 cada una espera un mensaje de su tarea predecesora en la secuencia de eventos. Como antes, la asignación de prioridades es, ta con la prioridad más alta, seguida respectivamente por las tareas t1, t2 y t3. La ejecución de estas cuatro tareas en un sistema de un sólo procesador se representa en la Figura 17.3 para el peor escenario cuando las tareas están listas para ejecutarse al mismo tiempo. Figura 17.3. Diagrama de timing para tareas en una secuencia de eventos ejecutándose en un sistema de un sólo procesador. 17.7.1. Análisis de funcionamiento de tareas independientes en sistemas multiprocesador Consideremos el ejemplo de las tres tareas descritas en la Sección 17.1.5 (y representadas en la Figura 17.1) ejecutándose en un sistema de doble procesador, donde se pueden ejecutar dos tareas en paralelo una en la CPU A y la otra en la CPU B. La ejecución de las tres tareas se ilustra en el diagrama de timing mostrado en la Figura 17.4. La ejecución se representa con partes sombreadas que identifican tareas ejecutándose en la CPU A o CPU B. Debido a que en este ejemplo hay dos CPUs, dos tareas se pueden ejecutar en cualquier momento, siempre que estén listas para ejecutarse. Considere el peor escenario cuando las tres tareas están listas para ejecutarse al mismo tiempo y cuando hay dos CPU disponibles. Este escenario comienza con t1 ejecutándose en la CPU A y t2 ejecutándose en la CPU B, esto se debe a que tanto t1 como t2 tienen los períodos más cortos y, por tanto, mayores prioridades que t3. La tarea t1 completa su ejecución en la CPU A después de 20 ms y por lo tanto cumple su plazo. Luego la tarea t3 comienza a ejecutarse en la CPU A mientras que la tarea t2 continúa ejecutándose en la CPU B. Después de 10 ms más, la tarea t2 completa su ejecución (fácilmente cumple su plazo) en la CPU B, luego de lo cual la CPU B se queda inactiva, ya que la tarea t1 aún no está lista para reanudar su ejecución. Al comienzo del segundo período de la tarea t1, T1 = 100, la tarea t1 reanuda su ejecución, pero esta vez en la CPU B. Después de 90 ms, la tarea t3 completa su ejecución, con un tiempo transcurrido total de 110 ms menor a su plazo de 200 ms. Como no hay tareas listas, la CPU A se queda inactiva. Después de 20 ms, la tarea t1 completa su ejecución y como no hay tareas listas, la CPU B pasa de nuevo a estar inactiva. En este momento, ambas CPUs están inactivas. La tarea t2 reanuda su ejecución de nuevo al comienzo de su segundo período, T2 = 150, en la CPU A y termina 30 ms después. Ahora considere las mismas tareas ejecutándose con la planificación dividida en lugar de la planificación global. Asumir que las tareas están divididas de tal forma que a las tareas t1 y t3 se les asigna la CPU A y a la tarea t2 se le asigna la CPU B. No hay ninguna diferencia en la ejecución hasta el comienzo del segundo período de t1, T1 = 100. Con la planificación dividida, la tarea t1 reanuda su ejecución en la CPU A (en lugar de la CPU B) al expropiar a la tarea t3, que para entonces ha estado ejecutándose por 80 ms. La tarea t1 completa su ejecución después de 20 ms, tiempo en el cual la tarea t3 reanuda su ejecución en la CPU A y completa su ejecución después de otros 10 ms. La tarea t2 reanuda su ejecución al inicio de su segundo período, T2 = 150, pero esta vez en la CPU B en lugar de la CPU A. Así todas las tareas cumplen sus plazos Comparando la planificación dividida con la planificación global para este ejemplo, todas las tareas cumplen sus plazos en ambos casos. De hecho, no hay diferencia en los tiempos transcurridos para tareas t1 y t2. Sin embargo, el tiempo transcurrido para la tarea t3 se extendió de 110 ms con la planificación global hasta 130 ms con la planificación dividida, que también es menor que su plazo de 200 ms. (El diagrama de timing para la planificación dividida no se muestra y se deja como ejercicio para el lector). Estos ejemplos muestran cómo las tareas pueden tomar ventaja de un procesador adicional al cumplir sus plazos mucho antes que con un sistema de un sólo procesador descrito en la Sección 17.1.5. Sin embargo, a menudo son muchos los casos donde las tareas no pueden tomar ventaja de un segundo procesador (o más) procesador(es), ya que se mantienen a la espera de un recurso escaso (como la memoria compartida o las E/S) o esperando por el mensaje de otra tarea. Así mismo, la contención de memoria también pude afectar negativamente al funcionamiento de los sistemas multinúcleo. 17.7.2. Análisis de funcionamiento de sistemas multiprocesador con exclusión mutua Consideremos ahora el caso de las cuatro tareas descritas en la Sección 17.3.6 (y representadas en la Figura 17.2), ejecutándose en un sistema de doble procesador, donde tres de las tareas tienen acceso mutuamente excluyente a una sección crítica. Asumamos el mismo peor escenario cuando todas las tareas están listas para ejecutarse al mismo tiempo. En esta situación, las dos tareas de mayor prioridad, ta y t1, se ejecutan en paralelo en las CPUs A y B, respectivamente, tal como se representa en la Figura 17.5. La tarea ta completa su ejecución en la CPU A después de 4 ms. Sin embargo, debido a que la tarea t1 tiene acceso mutuamente excluyente a su sección crítica por la duración de su ejecución, ni t2 ni t3 se pueden ejecutar ya que ambas están bloqueadas esperando entrar en sus secciones críticas; en consecuencia, la CPU A queda inactiva. Cuando la tarea t1 deja su sección crítica justo antes de completar su ejecución en la CPU B, la tarea t2 se desbloquea y se comienza a ejecutar en la CPU A entrando a su sección crítica. Sin embargo, la tarea de menor prioridad t3, permanece bloqueada y no puede tomar ventaja de una CPU libre. Cuando la tarea t2 deja su sección crítica antes de completar su ejecución en la CPU A, t3 se desbloquea y comienza a ejecutarse en la CPU B entrando a su sección crítica. Figura 17.5. Diagrama de timing para tareas ejecutándose en un sistema de doble procesador con exclusión mutua. Este ejemplo muestra que, en los sistemas multiprocesador, existen situaciones donde las tareas concurrentes no pueden sacar ventaja de las CPUs disponibles porque las tareas están bloqueadas a la espera de recursos escasos. 17.7.3. Análisis de funcionamiento de sistemas multiprocesador con el análisis de secuencia de eventos Consideremos ahora la aplicación del enfoque de análisis de secuencia de eventos para tareas que se ejecutan en un sistema de doble procesador. Este ejemplo usa las mismas cuatro tareas con los mismos tiempos de CPU y períodos de aquellas descritas en la Sección 17.3.6 y representadas en la Figura 17.3. Sin embargo, esta vez se considera la situación donde tres de estas tareas están involucrados en una secuencia de eventos donde las tareas se ejecutan en el orden t1, t2 y t3, de tal forma que la tarea t1 se activa por un evento externo, y las tareas t2 y t3 cada una espera un mensaje de su tarea predecesora en la secuencia de eventos. Como antes, la asignación de prioridades es, ta con la prioridad más alta, seguida respectivamente por las tareas t1, t2 y t3. La ejecución de estas cuatro tareas en un sistema con dos procesadores se representa en la Figura 17.6 para el peor escenario cuando todas las tareas están listas para ejecutarse al mismo tiempo. En esta situación, las dos tareas de mayor prioridad, ta y t1, comienzan a ejecutarse en paralelo en las CPUs A y B, respectivamente. Después de 4 ms la tarea ta completa su ejecución en la CPU A. Sin embargo, ya que las tareas t2 y t3 están bloqueadas a la espera de mensajes, ninguna de estas tareas se puede ejecutar, y por lo tanto la CPU A pasa a estar inactiva. Justo antes de completar su ejecución en la CPU B, la tarea t1 envía un mensaje a la tarea t2. La tarea t2 entonces se desbloquea y se ejecuta en la CPU A. Sin embargo, la tarea de menor prioridad t3, permanece bloqueada a la espera de un mensaje de t2 y no puede tomar ventaja de una CPU libre. Cuando la tarea t2 envía el mensaje a la tarea t3, t3 se desbloquea y se ejecuta en la CPU B. Figura 17.6. Diagrama de timing para tareas en una secuencia de eventos ejecutándose en un sistema de doble procesador. Como con el ejemplo de la sección anterior, este ejemplo de aplicación de análisis de secuencia de eventos muestra que, en los sistemas multiprocesador, existen situaciones donde las tareas concurrentes no pueden sacar ventaja de las CPUs disponibles porque en este caso las tareas están bloqueadas a la espera de mensajes de otras tareas. 17.8. Estimaciones y mediciones de los parámetros de funcionamiento Se deben determinar varios parámetros de funcionamiento a través de estimaciones o mediciones antes de llevarse a cabo un análisis de funcionamiento de tiempo real. Estas son variables independientes cuyos valores son entradas para el análisis de funcionamiento. Las variables dependientes son variables cuyos valores se estiman por la teoría de planificación de tiempo real. Un supuesto importante que se hace en la planificación de tiempo real es que todas las tareas están bloqueadas en la memoria principal, así que no existe overhead de paginación. El overhead de paginación añade otro grado de incertidumbre y retrasos que no se pueden tolerar en sistemas de tiempo real rígidos. Los siguientes parámetros se deben estimar para cada tarea implicada en el análisis de funcionamiento: a. El período Ti de la tarea, que es la frecuencia con la que se ejecuta. Para una tarea periódica, el período es fijo (véase el Capítulo 13 para más detalles sobre tareas periódicas). Para una tarea no-periódica, usar el peor escenario, es decir el tiempo mínimo entre llegadas del evento externo para una tarea de