prototipo de simulador de planificador de tareas …

PROTOTIPO DE SIMULADOR DEPLANIFICADOR DE TAREAS EN SISTEMAS

DE TIEMPO REAL CON PROCESADORESHETEROGÉNEOS

Trabajo Final Carrera Ingeniería de Sistemas Facultad de Ciencias Exactas – UNICEN

Alumno: Gariboldi, Diego Emanuel

Director: Prof. Ing. Aciti, Claudio

Dedicatoria y agradecimientos

Agradezco a mi familia, fuente de apoyo constante e incondicional en toda mi vida y más aún

en mis años de estudio. En especial quiero agradecer a mi esposa e hija que sin su ayuda

hubiera sido imposible culminar mi profesión.

A mi esposa, gracias por tu paciencia, comprensión y apoyo, éste logro es compartido porque

los dos somos uno y mis logros son tuyos. A mi hija, porque ella tuvo que soportar largas horas

sin la compañía de su papá, quizás sin entender por su corta edad, el porque su papá pasaba

tantas horas frente a la computadora y no acostado y/o jugando con ella. A pesar de ello,

compartimos siempre hermosos momentos y su sola sonrisa me llenaba de fuerzas.

También agradezco a todos mis amigos con los cuales compartí el camino del estudio y

siempre me apoyaron en los buenos y malos momentos.

Y por último, me gustaría agradecer a mi director de tesis Prof. Ing. Aciti Claudio, por haber

compartido sus conocimientos, orientaciones, su manera de trabajar y su paciencia que han

sido fundamentales en mi formación profesional.

3

Índice general

1. Introducción 3

1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Organización del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Estado Del Arte 9

2.1. Sistemas Heterogéneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2. Estrategias de planificación . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3. Cambio de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.4. Planificador por prioridades . . . . . . . . . . . . . . . . . . . . . . . 19

5

2.1.5. Deadline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1.6. Gestor de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.7. Factor de utilización . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.8. Computación paralela . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2. Sistemas de Tiempo Real (STR) . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2.1. Sistemas Operativos de Tiempo Real (SOTR) . . . . . . . . . . . . . . 31

2.2.2. Clasificación de los sistemas de tiempo Real . . . . . . . . . . . . . . 32

2.2.3. Planificación en sistemas heterogéneos de tiempo real . . . . . . . . . 34

2.2.4. Algoritmo de Mapeo AMTHA . . . . . . . . . . . . . . . . . . . . . . 35

3. Descripción del Problema 37

3.1. Sistema de tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2. Sistemas heterogéneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3. Sistema de tiempo real de tareas periódicas en procesadores heterogéneos . . . 39

3.4. Estructuras de datos usadas en un sistema . . . . . . . . . . . . . . . . . . . . 40

3.5. Paso a paso de la planificación de tareas . . . . . . . . . . . . . . . . . . . . . 40

3.6. Mecanismos para la planificación de tareas . . . . . . . . . . . . . . . . . . . . 41

3.7. Mecanismos para manejo de tareas no cumplidas por sobrecarga . . . . . . . . 42

6

4. Solución propuesta 43

4.1. Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1. Descripción del simulador . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2. Instrucciones para ejecutar una planificación . . . . . . . . . . . . . . 47

4.2. Casos testigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3. Generación de escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.3.1. Escenarios generados para testeo . . . . . . . . . . . . . . . . . . . . . 79

4.3.2. Resultados de los escenarios generados para testeo . . . . . . . . . . . 79

5. Conclusiones 97

6. Trabajos Futuros 99

7

Índice de figuras

2.1. Clasificación de las tareas según sus características temporales . . . . . . . . . 11

2.2. Clasificación de las tareas según sus características semánticas . . . . . . . . . 12

2.3. Parámetros de una tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4. Estrategia de planificación por lote . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5. Estrategia de planificación Apropiativa . . . . . . . . . . . . . . . . . . . . . . 16

2.6. Transición de estados de una tarea . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7. Cambio de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.8. Clasificación planificador por prioridades . . . . . . . . . . . . . . . . . . . . 20

2.9. Estrategia estática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.10. Estrategia dinámica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.11. Clasificación deadline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.12. Deadline aborto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9

2.13. Terminación tardía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.14. Modelo MIMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.15. Ejemplo 1: AMD Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.16. Ejemplo 2: Nvidia Tegra Die . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.17. Ejemplo 3: CPU combinado con una FPGA . . . . . . . . . . . . . . . . . . . 30

2.18. Clasificación de los sistemas de tiempo real . . . . . . . . . . . . . . . . . . . 34

3.1. Se observa una acción Ji,0 de una tarea τi . . . . . . . . . . . . . . . . . . . . . 38

4.1. Ventana principal de la herramienta en su estado inicial . . . . . . . . . . . . . 44

4.2. Descripción de la ventana principal de la herramienta en su estado inicial . . . 45

4.3. Estructura que debe cumplir el archivo a importar . . . . . . . . . . . . . . . . 48

4.4. Botón para comenzar la ejecución de la planificación . . . . . . . . . . . . . . 49

4.5. Botón para almacenar un resumen de la planificación . . . . . . . . . . . . . . 49

4.6. Planificación PF ABORTO instante 0 (cero) de tiempo . . . . . . . . . . . . . 50

4.7. Planificación PF ABORTO instante 2 (dos) y 3 (tres) de tiempo . . . . . . . . . 52

4.8. Planificación PF ABORTO instante 3 (tres) de tiempo . . . . . . . . . . . . . . 54

4.9. Planificación PF ABORTO instante 5 (cinco), 6 (seis) y 7 (siete) de tiempo . . . 55

10

4.10. Planificación PF FINALIZACIÓN TARDÍA instante 5 (cinco) y 6 (seis) de tiempo 56

4.11. Planificación PF ABORTO instante 9 (nueve) y 10 (diez) de tiempo . . . . . . 58

4.12. Planificación PF FINALIZACIÓN TARDÍA instante 9 (nueve) y 10 (diez) de

tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.13. Planificación PF FINALIZACIÓN TARDÍA instante 19 (diecinueve) y 20 (vein-

te) de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.14. Planificación PF FINALIZACIÓN TARDÍA instante 5 (cinco), 6 (seis) y 7 (sie-

te) de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.15. Planificación PF FINALIZACIÓN TARDÍA instante 12 (doce) de tiempo . . . 63

4.16. Planificación PF ABORTO instante 3 (tres), 4 (cuatro) y 5 (cinco) de tiempo . . 64

4.17. Planificación EDF FINALIZACIÓN TARDÍA instante 0 (cero), 1 (uno) y 2

(dos) de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.18. Planificación PF ABORTO instante 4 (cuatro) y 5 (cinco) de tiempo . . . . . . 66

4.19. Planificación PF ABORTO instante 1 (uno), 2 (dos) y 3 (tres) de tiempo . . . . 67

4.20. Planificación PF ABORTO instante 4 (cuatro) y 5 (cinco) de tiempo . . . . . . 69

4.21. Planificación PF FINALIZACIÓN TARDÍA instante 4 (cuatro) y 5 (cinco) de

tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.22. Planificación PF ABORTO periodo y cómputo de una tarea . . . . . . . . . . . 71

4.23. Detalle de las instancias que fallaron en la planificación PF y ABORTO . . . . 73

11

4.24. Detalle de las instancias que finalizaron correctamente en la planificación PF y

ABORTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

12

Índice de cuadros

4.1. Ejemplo 1 de definición de tareas . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2. Ejemplo 1 de definición de procesadores . . . . . . . . . . . . . . . . . . . . . 51


4.4. Ejemplo 2 de definición de procesadores . . . . . . . . . . . . . . . . . . . . . 62


4.6. Tipos de procesadores y sus clocks . . . . . . . . . . . . . . . . . . . . . . . . 75

4.7. Cantidad de procesadores de cada tipo . . . . . . . . . . . . . . . . . . . . . . 75

4.8. Ejemplo de generación de 5 (cinco) procesadores . . . . . . . . . . . . . . . . 76

4.9. Cantidad de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.10. Ejemplo de generación de 20 (veinte) tareas con FU=1.5 . . . . . . . . . . . . 78

4.11. Descripción de los escenarios de testeo . . . . . . . . . . . . . . . . . . . . . . 79

4.12. Resultados planificación escenario 1 con PF y Aborto . . . . . . . . . . . . . . 80

13

4.13. Resultados planificación escenario 1 con PF y Terminación Tardía . . . . . . . 81

4.14. Resultados planificación escenario 1 con EDF y Aborto . . . . . . . . . . . . . 82

4.15. Resultados planificación escenario 1 con EDF y Terminación Tardía . . . . . . 83













1

Capítulo 1

Introducción

Los sistemas heterogéneos han resultado atractivos durante la última década, ofreciendo

altos niveles de performance y uso de energía, comparados con los sistemas tradicionales con

un único procesador, sistemas monoprocesadores, donde el CPU era el encargado de ejecutar

todas las tareas programadas (Brodtkorb et al., 2010).

Con el fin de producir mejores rendimientos, se comenzó a utilizar dentro de una misma

computadora más de un procesador y se lo denominó sistemas multiprocesadores, en los que se

pueden distinguir los sistemas multiprocesadores homogéneos y los sistemas multiprocesadores

heterogéneos (Mednis et al., 2011) (Burns and Wellings, 2010).

Los sistemas heterogéneos, están formados por distintos procesadores pudiendo contener

uno o más de cada tipo. Estos sistemas, pueden utilizar una variedad de diferentes tipos de pro-

cesadores, por ejemplo, un procesador de propósito general (GPP) y un procesador de propósito

especial (GPU 1, FPGA 2) (Laplante, 1992).

Dentro de un sistema heterogéneo, en el cual sus procesadores tienen características dis-

1Graphics processing units2Field programmable gate array

3

tintas, es posible implementar un sistema de tiempo real. Un sistema de tiempo real, es aquel

encargado de producir respuestas dentro de un determinado tiempo finito, es decir, la calidad

de las respuestas del sistema se ve condicionada por el momento en que se producen las mis-

mas (Liu and Layland, 1973). Antiguamente, los sistemas de tiempo real solo eran utilizados en

las aplicaciones de las grandes industrias altamente automatizadas, en la exploración espacial

(Khatib, 1986), en dispositivos e instrumentos militares como aplicaciones capaces de detectar

fuego automáticamente (Healey et al., 1993), entre otros. Actualmente, este tipo de sistemas se

utilizan en una gran cantidad de dispositivos electrónicos de uso corriente (Orozco et al., 2013).

Básicamente un sistema está compuesto por un grupo de tareas o trabajos y un conjunto de

procesadores cuya función es la de ejecutar las tareas. Por ejemplo, una clásica representación

de un sistema de tiempo real, es una sucesión de trabajos que deben ser ejecutados en el/los

procesador/es, los trabajos compiten por el recurso procesador, por lo que se requiere una pla-

nificación de ejecución . Es por esto, que se tiene que realizar una buena planificación de sus

tareas que garantice el cumplimiento de las mismas . En los sistemas de tiempo real, la plani-

ficación de las tareas es muy importante ya que debe garantizar que se ejecuten, cumpliendo

con sus requisitos temporales, de no ser así el sistema no funcionará correctamente (Blanco de

Frutos et al., 2012) (Flores, 1995).

Los sistemas cuentan con un gestor de tareas, el cual tiene como función planificar el uso de

los procesadores. En el caso de los sistemas heterogéneos, es importante mantener el equilibrio

de carga del sistema entre los distintos procesadores para poder utilizar al máximo cada uno de

ellos, acompañado de una planificación eficiente (Luna et al., 2010) (Díaz et al., 2006).

Existen diferentes estrategias de planificación, que utilizan algoritmos con el fin de realizar

planificaciones eficientes para el sistema. El módulo encargado de implementar el algoritmo de

planificación, se denomina planificador. Muchos de los algoritmos de planificación, se basan

en los parámetros de las tareas, en especial en la prioridad, para producir sus planificaciones.

La prioridad, es un valor numérico que se le asigna a cada una de las tareas al momento de su

creación (Orozco et al., 2013).

4

Dentro de los algoritmos de planificación por prioridades, se destacan los algoritmos de

planificación por prioridades fijas (PF), los cuales mantienen fija la prioridad de cada tarea

durante toda su ejecución y los algoritmos de planificación por prioridades dinámicas (EDF),

los cuales no mantienen fija la prioridad de cada tarea, sino que la misma disminuye en cada

instante de tiempo durante la ejecución de su período (Liu and Layland, 1973).

En la actualidad, un conjunto de aplicaciones y frameworks existen en la literatura para

la simulación de planificaciones de tareas en sistemas de tiempo real. Entre los más relevan-

tes se pueden mencionar a STRESS (Audsley et al., 1994), PERTS (Liu et al., 1996), YASA

(Golatowski et al., 2002), Cheddar (Singhoff et al., 2004), RealTTS (Diaz et al., 2007) y el

simulador de la Université Libre de Bruxelles (Vroey et al., 1996). Aplicaciones como MAST

(González Harbour et al., 2001) ofrecen herramientas de modelado, y otras como FORTISSIMO

(Kramp et al., 2000) presentan una plataforma para el diseño de simulaciones.

1.1. Motivación

La atracción generada en la última década por los sistemas heterogéneos, ofreciendo mejor

performance, que los sistemas tradicionales (sistemas monoprocesadores y sistemas multipro-

cesadores homogéneos), produjo que el desarrollo de nuevas estrategias de planificación sea un

activo campo de investigación, debido a que los algoritmos de planificación juegan un impor-

tante papel en los sistemas heterogéneos (Mednis et al., 2011).

La planificación de las tareas, es una de las problemáticas más importantes a resolver por

los sistemas heterogéneos, con el fin de poder aprovechar el máximo potencial de cada com-

ponente. Para explotar todo el potencial de un componente heterogéneo es necesario asignar

correctamente la carga de trabajo. La planificación de tareas y el equilibrio de carga del sistema

se vuelven más complejos en los sistemas heterogéneo. En los sistemas de tiempo real, la pla-

nificación de las tareas es fundamental para garantizar que las tareas se ejecuten correctamente

5

dentro de los tiempos previamente asignados a cada tarea. En resumen, todo sistema busca rea-

lizar planificaciones eficientes de sus tareas, capaz de garantizar el cumplimiento de las mismas

(Díaz et al., 2006) (Flores, 1995).

Considerando éste contexto y la problemática de la planificación, que resulta fundamental

en todo sistema, junto con el déficit generado por no encontrar un software capaz de realizar

planificaciones de tareas en sistemas de tiempo real con procesadores heterogéneos, se propone

el desarrollo de un prototipo simulador, de un planificador de tareas, cuya planificación resul-

tante dependerá de las condiciones y/o restricciones previamente seleccionadas, el planificador

generará planificaciones de N tareas en M procesadores previamente cargados.

Para las planificaciones realizadas con el simulador, se utilizaran N tareas periódicas con

prioridades en M procesadores, pudiendo éstos ser procesadores distintos. Las tareas periódicas,

son aquellas que se repiten en un período de tiempo el cual se define como un parámetro mas

de la tarea. Además del uso de algoritmos de planificación por prioridades, el simulador contará

con dos políticas de acción en caso de que la instancia de una tarea alcance su tiempo máximo

de espera, siendo éstas Aborto, en la cual se abortará inmediatamente la instancia de la tarea

que alcance el tiempo máximo de espera o Terminación tardía, en la cual se descartara/n la/s

instancia/s siguiente/s a la que alcance el tiempo máximo de espera, otorgándole tiempo a la

instancia para que la misma finalice su ejecución (Páez et al., 2014) (Blanco de Frutos et al.,

2012).

1.2. Objetivo

El objetivo es el desarrollo e implementación de un prototipo de simulador de planificador

de tarea en sistemas de tiempo real con procesadores heterogéneos, en el cual, un usuario podrá

elegir distintas combinaciones de algoritmos de planificación.

6

Se utilizarán algoritmos de planificación por prioridades, pudiéndose elegir planificar por

prioridades fijas (PF) o planificar por prioridades dinámicas (EDF).

El simulador realizará planificaciones de N tareas en M procesadores (pudiendo estos ser

distintos), y a cada tarea se le podrá indicar en que tipo de procesador podrá ejecutarse, ya que

al trabajar con sistemas heterogéneos puede darse el caso de que una tarea sea ejecutable en

mas de un tipo de procesador o por lo contrario que una tarea pueda ejecutarse en un tipo de

procesador y no en otro.

1.3. Alcance

Se utilizarán algoritmos de planificación por prioridades, pudiéndose elegir planificar por

prioridades fijas (PF) o planificar por prioridades dinámicas (EDF).

El simulador realizará planificaciones de N tareas en M procesadores (pudiendo estos ser

distintos), y a cada tarea se le podrá indicar en que tipo de procesador podrá ejecutarse, ya que

al trabajar con sistemas heterogéneos puede darse el caso de que una tarea sea ejecutable en

mas de un tipo de procesador o por lo contrario que una tarea pueda ejecutarse en una tipo de

procesador y no en otro.

1.4. Organización del trabajo

En el capítulo 1 se presenta una breve introducción, mencionando conceptos básicos de los

sistemas y los diferentes tipos de sistemas existentes, enfocándose en los sistemas multiproce-

sadores heterogéneos y en los sistemas de tiempo real. Se explica también, la motivación que

impulsó el desarrollo e implementación del simulador y se plantean los objetivos.

7

En el capítulo 2, se realiza un repaso por el estado del arte, donde se profundizan los con-

ceptos mencionados en la introducción sobre los sistemas haciendo foco en los sistemas hetero-

géneos y los sistemas de tiempo real. Además, se profundiza la investigación sobre los distintos

tipos de planificadores y los algoritmos existentes utilizados para realizar planificaciones de las

tareas que componen un sistema.

En el capítulo 3, se presenta el problema a resolver, enfocándose en la planificación de

tareas en un sistema multiprocesador heterogéneo donde se implementa un sistema de tiempo

real.

En el capítulo 4, se plantea la solución al problema planteado en el capítulo anterior, deta-

llándose la implementación del simulador y las pruebas realizadas para su testeo.

En el capítulo 5, se plantean las conclusiones obtenidas luego del estudio de los resultados

obtenidos con la solución planteada.

En el capítulo 6, se plantean los trabajos futuros.

8

Capítulo 2

Estado Del Arte

2.1. Sistemas Heterogéneos

Se define a los sistemas heterogéneos como, un sistema formado por distintos tipos de pro-

cesadores, pudiendo contener uno o más procesadores de cada tipo. Éstos sistemas, utilizan una

variedad de diferentes tipos de procesadores, por ejemplo, un procesador de propósito general

(GPP) y un procesador de propósito especial (GPU, FPGA) (Laplante, 1992).

Un sistema heterogéneo, es aquel que se encuentra compuesto por hardware con caracte-

rísticas físicas distintas entre sí, pero se pueden comunicar utilizando medios comunes, puede

contener procesadores con distintas velocidades de cómputo, así como los tiempos de transfe-

rencia de datos, pueden ser diferentes en las comunicaciones entre cada par de procesadores

(Orozco et al., 2013).

La velocidad de un procesador se define en función del número de operaciones por se-

gundo, así como el tiempo que requiere para realizar un acceso a memoria. La diversidad de

procesadores es importante para la computación heterogénea ya que cada tipo de procesador

9

tiene sus puntos fuertes y débiles. Mediante la utilización eficaz de diversos procesadores, la

computación heterogénea aumenta al máximo el rendimiento de aplicaciones, la eficiencia tér-

mica y la duración de baterías, entre otros (Moreno, 2004).

Antiguamente, los sistemas monoprocesadores, contaban con un único procesador (CPU)

el cual era el encargado de ejecutar todas las tareas programadas. Con el fin de producir mejores

rendimientos, se comenzó a utilizar sistemas multiprocesadores, los cuales están formados por

más de un procesador. Los sistemas de computación heterogénea 1, se han usado extensivamente

para resolver problemas complejos durante los últimos quince años, fundamentalmente, por la

capacidad de cómputo (Mednis et al., 2011) (Burns and Wellings, 2010) (Luna et al., 2010).

2.1.1. Tareas

Todo sistema, esta compuestos por un grupo de tareas o trabajos 2 y un conjunto de proce-

sadores cuya función es la de ejecutar las tareas. Se considera a una tarea, como una sucesión de

trabajos que se repiten a lo largo del tiempo, cuando una tarea comienza a ejecutarse comenzará

a ejecutarse su primer trabajo y cuando el último trabajo finalice, finalizará la ejecución de la

tarea (Laplante, 1992).

Clasificación de las tareas

Usualmente, no todas las tareas que se ejecutan en un sistema tienen la misma relevancia

a la hora de cumplir los plazos de ejecución, existen diferentes tipos de tareas como: “Ta-

reas periódicas”, “Tareas esporádicas”, “Tareas Críticas”, etc. En un sistema, pueden existir por

ejemplo tareas críticas y tareas con plazos de ejecución menos críticas, o también tareas sin

plazos de ejecución (Liu and Layland, 1973).

1En inglés,(HC) Heterogeneous Computing2En inglés, Jobs

10

Clasificación según sus características temporales: (Páez et al., 2014)

Tareas periódicas: Son tareas cuya ejecución se realiza periódicamente, es decir, sus tra-

bajos entran en ejecución en un periodo constante.

Tareas esporádicas: Son tareas que al igual que las tareas periódicas, tienen un plazo de

finalización estricto, pero no se ejecutan de forma periódica sino esporádicamente. Su

ejecución es ocasional o con poca frecuencia y a diferencia de las tareas periódicas, no se

puede predecir cuándo estará lista para ejecutarse.

Tareas aperiódicas: Son tareas no tienen plazo de finalización, o en caso de tenerlo, no

es condición obligatoria su cumplimiento, estas condiciones las diferencian de las tareas

periódicas.

Figura 2.1: Clasificación de las tareas según sus características temporales

Clasificación según sus características semánticas: (Rivas, 2002)

Tareas críticas: Son tareas que su fallo (por no ejecutarse a tiempo) puede ser catastrófico

para el sistema. El sistema no debería continuar con su ejecución en caso que una tarea

de este tipo falle.

11

Tareas opcionales: Son tareas que si se retrasa su ejecución no afecta a la seguridad del

sistema. (Monitorización del sistema, Tareas de mantenimiento, entre otras). Las tareas

opcionales las podemos dividir en dos grupos.

• Opcionales con plazo 3: Disponen de un tiempo de ejecución recomendado.

• Opcionales sin plazo 4: No disponen de un tiempo de ejecución recomendado.

Figura 2.2: Clasificación de las tareas según sus características semánticas

Parámetros de una tarea

Una tarea está compuesta por una serie de parámetros que afectan al comportamiento tem-

poral. Muchos de los algoritmos de planificación, se basan en los parámetros de las tareas, en

especial en la prioridad, para producir sus planificaciones. Una tarea es considerada para ser

ejecutada antes que otra, si tiene mayor prioridad (Crespo and Alonso, 2006)(Pérez, 2003).

Estos parámetros son:

Pi : Periodo de activación, si es periódico. También conocido como “periodo”, es el

instante de tiempo en que la tarea se encuentra activa para ejecutarse, si se llega al final del3En inglés, Hard aperiodic4En inglés, Soft aperiodic

12

periodo y la tarea no terminó su ejecución entonces falla. Si el proceso es esporádico, se

tratará como un proceso periódico con período igual al mínimo tiempo entre activaciones.

Ci : Tiempo máximo de ejecución, también conocido como “tiempo de cómputo” de la

tarea.

Di : Plazo máximo de terminación, también conocido como Deadline.

Ri : Tiempo de respuesta máximo. Es el tiempo desde que la tarea se activa hasta que

termina de ejecutarse.

Pri : Prioridad de la tarea (convenio: mayor valor numérico, menor prioridad).

Si : Desfase respecto al momento inicial.

Figura 2.3: Parámetros de una tarea

2.1.2. Estrategias de planificación

Todo sistema, debe realizar una buena planificación de sus tareas, que garantice el cumpli-

miento de las mismas. Existen diferentes estrategias de planificación, que utilizan los algoritmos

con el fin de realizar planificaciones eficientes para el sistema. (Blanco de Frutos et al., 2012).

13

En un sistema, sin importar el número de procesadores que contenga, se deben asignar los

trabajos a los procesadores en un orden determinado para que sean ejecutados. El modulo que

implementa el algoritmo que decide que trabajo ejecuta cada procesador y en que orden, se

denomina planificador. Éste es el encargado de que el sistema pueda garantizar con el cumpli-

miento de los vencimientos de las tareas, para esto, debe elegir a que tarea otorga el derecho

de ejecución en cada procesador, una vez que tarea se instancia o termina, el planificador de-

be examinar la cola de tareas listas y dependiendo de la política de prioridades implementada,

elegir la siguiente para su ejecución (Orozco et al., 2013) (Luna et al., 2010).

La planificación es fundamental de un sistema, se entiende por planificación, a una asigna-

ción concreta de trabajos a procesadores, en intervalos de tiempo determinados. Generalmente

se habla de dos clases de planeamiento o políticas de planeamiento: previa a la ejecución 5 ó

durante la ejecución 6 (Flores, 1995).

Se pueden distinguir dos estrategias básicas de planificación:

Planificación por Lote: Consiste en asignar la CPU por turnos, es decir, a un tarea se

le asigna una CPU y no se permite la interrupción de la misma hasta que finalice el

trabajo/instancia. De esta manera, una tarea, utiliza una CPU un tiempo igual al su tiempo

de cómputo, cuando se libera la CPU, es asignada a la siguiente tarea de la lista. En ésta

estrategia se minimiza el tiempo de conmutación entre tareas (cambio de contexto 7) y

es efectiva en pequeños sistemas donde los tiempos se pueden calcular cuidadosamente;

es una estrategia que requiere que los tiempos de las tareas sean lo más similar posible

y que no se caracteriza por beneficiar a las tareas de mayor prioridad, pudiendo suceder

que una tarea de mayor prioridad espere la finalización de una tarea de menor prioridad.

Ejemplo: Se implementa un procesador y dos tareas T1 y T2 con las siguientes caracte-

rísticas:5En inglés, Pre-run-time6En inglés, Run-time scheduling7En inglés, Context switching

14

T 1⇒ Pr1 = 1,C1 = 3,P1 = 5,D1 = P1

T 2⇒ Pr2 = 4,C2 = 5,P2 = 5,D2 = P2

Además T1 se comienza a ejecutar en el instante 2 (dos) de tiempo.

La ejecución con esta estrategia sería:

Figura 2.4: Estrategia de planificación por lote

Como se observa en el ejemplo, la tarea T1 , de mayor prioridad espera para tomar

control de la CPU a que T2 lo libere, sin considerar que T2 es de menor prioridad.

Planificación Apropiativa 8: Consiste en asignar la CPU a una tarea dada en un tiempo

determinado, pero la misma puede ser interrumpida y desalojada antes que haya finali-

zado su ejecución. Debido a esto es necesario realizar un cambio de contexto cada vez

que conmutan las tareas. Existen diferentes estrategias por las que una tarea puede ser

desalojada por ejemplo round-robin, por prioridades, etc.(Krause et al., 2008).

En una estrategia por prioridades y apropiativa, una tarea de mayor prioridad no debe

esperar para ejecutarse si en el procesador se está ejecutando una de menor prioridad, en

ese caso se debe realizar un cambio de contexto y comenzar la ejecución de la tarea de

mayor prioridad, es ahí cuando se ve que la tarea de mayor prioridad se apropia del CPU

(Liu and Layland, 1973).8En inglés, Pre-emptive

15

Ejemplo: Se define un planificador apropiativo por prioridades, en el cual se implementa

un procesador y dos tareas T1 y T2 con las siguientes características:

T 1⇒ Pr1 = 1,C1 = 3,P1 = 5,D1 = P1

T 2⇒ Pr2 = 4,C2 = 5,P2 = 5,D2 = P2



Figura 2.5: Estrategia de planificación Apropiativa

Como se ve en el ejemplo, a diferencia del caso anterior, la tarea T1 , de mayor prioridad

no espera para tomar control de la CPU y desaloja a T2 la cual se almacena en la cola

de tareas listas, a la espera de tomar nuevamente el control de la CPU y continuar su

ejecución, se genera un cambio de contexto.

2.1.3. Cambio de contexto

El cambio de contexto, se produce cuando una tarea que está siendo ejecutada en una

CPU determinada, debe ser desalojada para que su lugar sea ocupado por una nueva tarea.

Al producirse un cambio de contexto, es necesario que se almacene el entorno de cada tarea

16

desalojada ya que posteriormente se le podrá asignar tiempo de CPU y debe continuar desde el

punto exacto donde fue interrumpida (Krause et al., 2008)(Rivas, 2002).

Una tarea va cambiando de estados hasta que finaliza su ejecución. La transición de estados

de una tarea son:

Figura 2.6: Transición de estados de una tarea

Ejecutándose: La tarea tiene el control de la CPU.

Lista: La tarea está lista para utilizar la CPU, pero no dispone de ella porque la está

utilizando otra tarea.

Suspendida : La tarea finaliza su ejecución y está en espera de una nueva activación o

necesita de un recurso que no está disponible.

Ejemplo:

Se implementa un procesador y dos tareas T1 y T2 con las siguientes características:

T 1⇒ Pr1 = 1,C1 = 3,P1 = 5,D1 = P1

T 2⇒ Pr2 = 4,C2 = 5,P2 = 5,D2 = P2

17



Figura 2.7: Cambio de contexto

Se observa que en el instante 1 (uno) de tiempo, se produce un cambio de contexto, debido

a que la tarea T2 se estaba ejecutando en el procesador, pero al estar lista la tarea T1 para

ejecutarse y tener mayor prioridad, se desalojó T2 del procesador y comenzó a ejecutarse T1 .

El contexto de una tarea guarda el estado del procesador justo antes de que otra tarea tome

el control de este. Se puede implementar con un puntero a la próxima instrucción que se debe

ejecutar 9, la dirección actual de la parte alta de la pila 10 y el contenido de los registros de

propósito general y los flags de estado. Por lo tanto el cambio de contexto supone guardar el

contexto de la tarea anterior y cargar el contexto de la nueva tarea. Esta parte de código es

específica de cada procesador (Pérez, 2003).

9En inglés, Instruction pointer10En inglés, Stack pointer

18

2.1.4. Planificador por prioridades

Para para poder implementar un planificador por prioridades, es necesario asignarle a cada

tarea una prioridad, la cual es un valor numérico que se usa como factor para determinar que

tarea se apodera de la CPU antes que otra(s). Se le otorga mayor prioridad, a las tareas que

tenga especificaciones de tiempo más severas y sean vitales para el correcto funcionamiento del

sistema. En tiempo de ejecución siempre se intentara ejecutar la/s tarea/s de mayor prioridades

que se encuentren activas en cada instante de tiempo (Liu and Layland, 1973).

La asignación de prioridades puede ser de dos tipos:

Estáticas: La prioridad de cada tarea permanece constante en cada instancia de tiempo,

durante toda la ejecución del sistema.

Dinámicas: La prioridad de cada tarea varía en cada instante de tiempo, dependiendo las

reglas definidas.

Una desventaja de la planificación por prioridades estáticas o fijas es la inanición 11, la asigna-

ción dinámica de prioridades intenta resolver ésta situación.

En conclusión, un planificador basado en el concepto de prioridades, asigna el procesador

a la tare de mayor prioridad entre todas las que están activas. Generalmente se considera que

una tarea posee mayor prioridad que otra cuando el número que representa la prioridad es mas

chico, generalmente la mayor prioridad corresponderá al valor 0 y la prioridad será menor según

aumenta su valor (Crespo and Alonso, 2006).

11Inanición, en inglés starvation, es cuando un proceso/tarea queda esperando debido a que siempre hay alguna

tarea con mayor prioridad lista para ejecutarse.

19

Figura 2.8: Clasificación planificador por prioridades

Planificador con prioridades estáticas

Cuando las prioridades de todas las tareas del sistema se mantienen constantes a lo largo

del tiempo, se considera que la asignación de prioridades es estática. Ésta política de asignación

de prioridades es la muy utilizada en los sistemas de tiempo real comerciales, sin embargo,

puede no ser óptima y conducir a fallos en tiempos de respuesta de algún proceso, incluso hacer

que el procesador sea poco utilizado (Crespo and Alonso, 2006).

Otra desventaja de este tipo de asignación estática, es la inanición de las tareas. La imple-

mentación de este tipo de planificador es relativamente sencilla, ya que las prioridades de las

tareas no varían.

Entre los planificadores con prioridades estáticas, los más importantes son: (Liu and Lay-

land, 1973)

Rate Monotonic (RM): Se asignan las prioridades según el periodo. La tarea de menor

período, se le asigna la mayor prioridad.

Deadline Monotonic (DM): Se asignan las prioridades según sus plazos. La tarea con el

plazo más corto, se le asigna la mayor prioridad.

20

Ejemplo: Supongamos que tenemos un planificador con prioridades estáticas y dos tareas T1 y

T2 con las siguientes características:

T 1⇒ Pr1 = 1,C1 = 3,P1 = 5,D1 = P1

T 2⇒ Pr2 = 4,C2 = 5,P2 = 5,D2 = P2



Figura 2.9: Estrategia estática

Como se puede observar en el ejemplo, las tareas no modifican sus prioridades a lo largo

de la ejecución, en cada ciclo se ejecutaran en el mismo orden siempre que no se agregue una

nueva tarea que modifique el orden. Éste tipo de planificador corre el riesgo de tener una tarea

que no se ejecute nunca ya que otras tareas tienen prioridad de ejecución sobre ella.

Planificador con prioridades dinámicas

Este tipo de planificador, al igual que el de prioridades estáticas, basa su planificación en

las prioridad de cada tarea, y se caracteriza porque las prioridades no se mantienen estáticas,

21

sino que varían durante el tiempo de ejecución (Crespo and Alonso, 2006).

Al igual que en el caso anterior, en cada instante de tiempo se ejecutan las tareas que tengan

mayor prioridad, en éste tipo de planificador se obtienen mejores factores de utilización que con

los métodos de asignación estática y los resultados obtenidos se pueden generalizar a sistemas

de procesos interactivos (Liu and Layland, 1973).

Los algoritmos de planificación basados en prioridades dinámicas, presentan dos importan-

tes ventajas: aprovechan al máximo la potencia del procesador y se adaptan muy bien a entornos

altamente dinámicos evitando la inanición que se podía producir con las asignaciones estáticas

(Rivas, 2002).

Básicamente se utilizan dos planificadores dinámicos, estos son: (Liu and Layland, 1973)

EDF 12. Se asignan las prioridades dando preferencia a las tareas con plazo de finalización

más próximo.

LLF 13. Se asignan las prioridades dando preferencia a las tareas con menor holgura.

Ejemplo: Supongamos que tenemos un planificador con prioridades dinámicas y dos tareas

T1 y T2 con las siguientes características:

T 1⇒ Pr1 = 1,C1 = 3,P1 = 5,D1 = P1

T 2⇒ Pr2 = 4,C2 = 5,P2 = 5,D2 = P2



12En inglés Earliest Deadline First13En inglés Least Laxity First

22

Figura 2.10: Estrategia dinámica

Como se puede observar en el ejemplo, las tareas modifican sus prioridades a lo largo de la

ejecución, en cada instante de tiempo, las prioridades de las tareas se reduce, lo cual modifica

el orden de ejecución que ya no será fijo como en el caso anterior, esto ayuda a prevenir la

inanición de una tarea.

2.1.5. Deadline

El deadline se produce cuando la instancia de una tarea llega a su tiempo límite sin com-

pletar su ejecución, en ese caso, se dice que alcanzó su deadline o tiempo máximo de espera.

Cuando esto sucede, se debe contar con una política para decidir qué hacer con cada instancia

de las tareas que alcancen su tiempo máximo de espera, éstas políticas básicamente se basan en

sí se descarta o no la instancia de la tarea que no complete su ejecución y llegue a su tiempo má-

ximo. Dentro de estas políticas de decisión se distinguen las políticas “Aborto” y “Terminación

Tardía” (Burns and Wellings, 2010).

Aborto 14: Al implementar esta política, lo que se hace es descartar la instancia de la

14En inglés, Abortion

23

Figura 2.11: Clasificación deadline

tarea que no completa su ejecución y alcanza su deadline, y al momento de ejecutarse

nuevamente, la tarea continuará ejecutándose desde la instancia siguiente.

Ejemplo:

Figura 2.12: Deadline aborto

Terminación Tardía 15: Básicamente al implementar esta política, lo que se hace es com-

pletar la instancia que alcanzó su tiempo máximo consumiendo el tiempo de la instancia

siguiente, es decir, en este caso no se descarta la instancia que alcanzó su tiempo máximo,

15En inglés, Delayed Completion

24

sino que se descartan tantas instancias continuas como sean necesarias para completar la

ejecución de la instancia que alcanzó el tiempo máximo.

Ejemplo:

Figura 2.13: Terminación tardía

2.1.6. Gestor de tareas

Todo sistema, cuenta con un gestor de tareas, cuya función es planificar el uso de los

procesadores.

Sus funciones son:(Luna et al., 2010)

Mantener un registro del estado de cada tarea.

Planificar el uso de la CPU, decide qué tarea se ejecuta en cada instante de tiempo.

Realizar en caso de ser necesario el cambio de contexto entre procesos.

Es importante mantener un registro de cada tarea para llevar control de su estado en cada

instante de tiempo. Las tareas compiten por el uso de la CPU para realizar su ejecución y en cada

25

instante de tiempo el gestor de tarea debe evaluar todas las tareas que están listas para ejecutar

y asignar el CPU a la tarea que cumpla con los requisitos del planificador, generalmente se

comparan las prioridades de las tareas, pero hay que tener en cuenta todas las propiedades del

planificador para poder decidir correcta y eficazmente (Crespo and Alonso, 2006).

2.1.7. Factor de utilización

Los sistemas heterogéneos, deben mantener el equilibrio de carga del sistema entre los

distintos procesadores para poder utilizar al máximo cada uno de ellos, acompañado de una

planificación eficiente. El factor de utilización, se define como la fracción de tiempo que el

procesador está ocupado ejecutando procesos y se representa con la siguiente fórmula: (Díaz

et al., 2006)

U =N

∑i=1

Ci

Pi

Un sistema utiliza completamente el procesador si la planificación realizada es admisible.

El factor de utilización es una medida de carga, mide el porcentaje de procesamiento que se rea-

liza. Para que un conjunto de tareas periódicas se puedan ejecutar en un procesador, es necesario

que el factor de utilización sea menor o igual que 1 (uno), en caso contrario, alguna/s instancia/s

de las tareas podrían alcanzar su tiempo máximo de espera y tener que ser abortadas. En caso

que el U , sea mayor a 1 o al 100% se produce una sobrecarga en el sistema, produciendo un

strees en el mismo (Olguín et al., 2012).

U ≤ 1

El Factor de Utilización Garantizado para n procesos, UGn , es el valor mínimo del factor

de utilización (U), entre los correspondientes a todos los STR con n procesos que utilizan com-

pletamente el procesador. Al tratarse de un valor mínimo, pueden existir sistemas de tiempo real

26

en los que sea posible alcanzar factores de utilización mayores que el garantizado. El sentido de

este valor es que se garantiza que exista una planificación admisible siempre que: (Luna et al.,

2010)

U ≤UGn

Se puede asegurar que existe una planificación admisible con prioridad estática si el factor de

utilización es inferior a 0,7 . No obstante, en algunos casos, se pueden alcanzar valores más

altos del factor de utilización. Tener un U del 69% es lo que se conoce como limite teórico

aceptable, superando este porcentaje se transforma en cuestionable o peligrosa la planificación

y carga en el CPU (Laplante, 1992).

El factor de utilización medio, generalmente, estará muy por debajo del máximo garanti-

zado (Olguín et al., 2012).

2.1.8. Computación paralela

El término “computación paralela” frecuentemente se solapa con el término “computación

distribuida” y no hay una distinción clara entre ambos, ocurriendo a menudo que un mismo

sistema sea clasificado en ambas categorías. Se pueden utilizar los siguientes criterios para

distinguir un sistema paralelo de uno distribuido: (Aguilar et al., 2004)

En un sistema paralelo, todos los procesadores (homogéneos o heterogéneos) tienen acce-

so a una memoria compartida. Ésta memoria, es utilizada para intercambiar información

entre los procesadores.

En un sistema distribuido, cada procesador tiene su propia memoria privada, la informa-

ción es intercambiada entre procesadores mediante el uso de mensajes.

27

Utilizando los criterios antes mencionados, podemos concluir que la diferencia entre un

sistema y otro lo proporciona la forma en que cada procesador accede a la memoria (Blanco de

Frutos et al., 2012).

En los sistemas paralelos varios procesadores trabajan juntos para resolver una tarea co-

mún, cada procesador trabaja en una porción del problema, y pueden intercambiar datos a través

de la memoria . La memoria al ser compartida por todos los procesadores del sistema se trans-

forma en la mayor limitación de los mismos. Dentro de las ventajas que presentan este tipo

de sistema podemos mencionar que perminten resolver problemas mayores y de manera mas

eficiente (Moreno, 2004).

Dentro de los modelos de computadores paralelos existentes, nos centraremos en el mo-

delo MIMD 16, en el que cada procesador se encarga de ejecutar un programa diferente inde-

pendientemente de los otros procesadores. También podemos mencionar el modelo de memoria

distribuida 17 y el modelo de memoria compartida 18 (Aguilar et al., 2004).

Figura 2.14: Modelo MIMD

16Multiple Instruction Multiple Data17Cada procesador tiene su propia memoria local18Un único espacio de memoria, donde todos los procesadores tienen acceso

28

Actualmente se pueden encontrar varios tipos de procesadores específicos en el mercado

como por ejemplo GPU, DSP 19, FPGA y heterogéneos embebidos, PSP 20, entre otros. Un

ejemplo sencillo de computadores heterogéneos es un computador formado por un CPU + GPU.

Ejemplos:

Figura 2.15: Ejemplo 1: AMD Fusion

Figura 2.16: Ejemplo 2: Nvidia Tegra Die

19Procesador de tratamiento de señal20Procesador de juegos

29

Figura 2.17: Ejemplo 3: CPU combinado con una FPGA

2.2. Sistemas de Tiempo Real (STR)

Se considera a un sistema, como un conjunto de entradas y salidas, muchos autores analizan

las entradas y salidas de los sistemas y lo ven como a una caja negra. Un sistema de tiempo

real es aquel que debe producir respuestas correctas dentro de unos límites de tiempo. Una

clásica representación de un sistema de tiempo real, es una sucesión de trabajos que deben ser

ejecutados en el/los procesador/es, los trabajos compiten por el recurso procesador, por lo que

se requiere una planificación de ejecución (Laplante, 1992).

Los Sistemas de tiempo real, se definen como sistemas informáticos que tienen la capa-

cidad de interactuar rápidamente con su entorno físico, el cual puede realizar funciones de

supervisión o control para su mismo beneficio (Burns and Wellings, 2010).

Los sistemas de tiempo real, son sistemas de tiempo crítico, es decir, se trata de aplica-

ciones para las cuales el tiempo en que se produce la respuesta es un requerimiento esencial.

Antiguamente, los sistemas de tiempo real eran utilizados en las aplicaciones de las grandes

industrias altamente automatizadas, en la exploración espacial (Khatib, 1986), en dispositivos e

instrumentos militares como aplicaciones capaces de detectar fuego automáticamente (Healey

et al., 1993), entre otros. Actualmente, este tipo de sistema se utiliza en una gran cantidad de

30

dispositivos electrónicos de uso corriente (Orozco et al., 2013), por ejemplo, sistemas de na-

vegación en tiempo real (Hernández et al., 1999). Los sistemas de tiempo real, generalmente

están operados por tareas periódicas que incluyen entre sus parámetros los máximos tiempos de

respuesta admisibles por la aplicación. Si la tarea finaliza luego de su tiempo de vencimiento,

se dice que ha perdido su constricción temporal (Ramón and Romero, 2002).

2.2.1. Sistemas Operativos de Tiempo Real (SOTR)

Un sistema operativo de tiempo real, es un sistema operativo al cual se le exige respuestas

bajo ciertas restricciones de tiempo (Burns and Wellings, 2010).

Una necesidad fundamental de un sistema operativo, es asignar recursos del computador

a las diversas actividades. En un sistema operativo de tiempo real, éste proceso es sumamente

importante y complejo de realizar debido que algunas actividades son temporalmente críticas

con mayor prioridad. Es por este motivo que se debe contar con un planificador de tareas (Liu

and Layland, 1973).

Un sistema de tiempo real, debe:(Pérez, 2003)

Ser diseñado para responder incluso ante varias formas de fallos, pretendiendo que se

pueda recuperar ante una falla y se logre una estabilidad. Muchos Sistemas Operativos

de tiempo real son construidos para aplicaciones muy específicas como control de tráfico

aéreo, bolsas de valores, control de refinerías, control de laminadores.

Responder en un intervalo prefijado o ante eventos externos de una manera determinista,

sin importar el impacto que esto genere sobre las demás tareas y/o procesos del sistema.

La eficiencia de los sistemas de tiempo real, no solo depende de la exactitud de los re-

sultados de cómputo, sino también del momento en que los entrega. La predictibilidad, es una

31

característica principal en este tipo de sistemas operativos, y se considera que un sistema ope-

rativo de tiempo real, funciona correctamente cuando produce el resultado correcto dentro de

un intervalo de tiempo previamente estipulado, estas restricciones temporales son fijas y bien

definidas (Liu and Layland, 1973).

Generalmente, los sistemas operativos de tiempo real suelen tener la misma arquitectura

que un sistema operativo convencional, pero su diferencia radica en que proporciona mayor

prioridad a los elementos de control y procesamiento que son utilizados para ejecutar los proce-

sos o tareas, otra diferencia fundamental entre un sistema de tiempo real y un sistema operativo

en tiempo compartido, es el algoritmo de planificación para la asignación de la CPU. A dife-

rencia de los sistemas de tiempo compartido, el sistema de tiempo está diseñado para brindarle

mayor importancia a los procesos que a los usuarios (Pérez, 2003).

2.2.2. Clasificación de los sistemas de tiempo Real

Los sistemas de tiempo real, se pueden clasificar en dos tipos de sistemas, que a su vez se

subdividen considerando la severidad en el tratamiento de errores, provocados por el incumpli-

miento de alguna de las tareas debido a que no completó su ejecución y alcanzó su deadline

(Laplante, 1992).

Se puede observar en la figura 2.18 la representación de la clasificación de los sistemas de

tiempo real.

Los sistemas de tiempo real se clasifican en:

Sistemas de Tiempo Real Blandos/Suaves 21: Estos sistemas se caracterizan por tolerar un

exceso en el tiempo de respuesta y garantizar que las tareas críticas se ejecutan en tiempo.

Almacenan los datos en memoria no volátiles y no puede ser implementada en hardware.

21En inglés, Soft real-time systems

32

Se permite que se pierdan ocasionalmente algunas especificaciones temporales. Es una

forma de caracterizar a sistema de tiempo real en el que se busca que el tiempo medio de

respuesta sea menor de un tiempo predefinido. Debido a que no apoyan el cumplimiento

estricto de plazos, es riesgoso utilizarlos en control industrial y robótica. Si un trabajo

crítico en tiempo real entra en el sistema, el sistema operativo puede asignar la máxima

prioridad a esta tarea y ejecutar de forma continua hasta que se complete (Burns and

Wellings, 2010).

Un sistema de tiempo real es blando cuando se degrada el rendimiento pero no es descar-

tado por el incumplimiento de las limitaciones de tiempo de respuesta.

• Tiempo Real Firme 22: es un sistema de tiempo real suave, y además el sistema no

obtiene beneficios de la pérdida ocasional de especificaciones temporales (Laplante,

1992).

Sistemas de Tiempo Real Duros 23: En este tipo de sistemas no se permite una respuesta

fuera de término, si esto sucede, se produce una falla en el sistema. Las respuestas se

deben producir antes del tiempo estipulado. Éste tipo de sistema garantiza que las tareas

críticas se terminaran a tiempo siempre, en caso contrario, falla. Se requiere que todos los

retardos del sistema estén limitados. Generalmente no hay almacenamiento secundario,

los datos se almacenan preferentemente en memoria de corto plazo. El sistema no pue-

de esperar indefinidamente por lo que los sistemas de tiempo real duro suelen ser muy

limitados.

Un sistema de tiempo real duro, es aquel en el que incumplimiento de solo plazo, puede

conducir al fallo completo y catastrófico del sistema (Laplante, 1992).

• Tiempo Real Real 24: Éste tipo de sistema, es un sistema de tiempo real duro en el

cual los tiempos de respuesta deben ser muy cortos (Burns and Wellings, 2010).

22En inglés, Firm real-time23En inglés, Hard real-time systems24En inglés, Real real-time

33

Figura 2.18: Clasificación de los sistemas de tiempo real

2.2.3. Planificación en sistemas heterogéneos de tiempo real

La asignación de recursos a las tareas, es un aspecto crucial cuando se utilizan grandes in-

fraestructuras de cómputo, ya que encontrar una planificación precisa para un conjunto de tareas

que se han de ejecutar en un sistema de este tipo, tiene un impacto de gran importancia tanto en

los costos de utilización de los recursos como en la calidad del servicio percibida por el usua-

rio. La atracción generada en la última década por los sistemas heterogéneos, ofreciendo mejor

performance, que los sistemas tradicionales, produjo que el desarrollo de nuevas estrategias de

planificación sea un activo campo de investigación, debido a que los algoritmos de planifica-

ción juegan un importante papel en los sistemas heterogéneos (Mednis et al., 2011)(Díaz et al.,

2006).

Un algoritmo de planificación 25, es un conjunto de reglas que determina la tarea a ejecutar

en un instante de tiempo particular (Liu and Layland, 1973).

Para los sistemas en tiempo real, es de suma importancia que el algoritmo de planificación

pueda predecir en todo momento que tarea se va a ejecutar el próximo instante de tiempo. Las

tareas de tiempo real, necesitan de prioridad para ser ejecutadas. Un típico sistema de tiempo

real esta compuesto por n tareas y para garantizar su correcta ejecución es necesario un meca-

25En inglés, Scheduling

34

nismo de planificación (Laplante, 1992).

El planificador 26, usualmente se ejecuta como una tarea del sistema operativo de tiempo

real, e implementa una disciplina de prioridades la cual permite determinar la próxima tarea a

ejecutar en un procesador. Las dos disciplinas más utilizadas en los sistemas de tiempo real, son

de prioridades fijas (FP) y de prioridades dinámicas (EDF), explicadas en la sección Planificador

con Prioridades Estáticas y Planificador con Prioridades Dinámicas. El planificador realiza una

distribución eficiente de las tareas, controlando la carga de cada procesador 27, evitando la

sobrecarga de alguno de ellos y que otro se encuentre ocioso. Las diferentes políticas y reglas

que se seleccionan para que el planificador cumpla impactará en la performance del sistema.

(Bogdanski et al., 2011).

El problema de la planificación es resuelta por un algoritmo que establece un mecanismo

automático que asigna tarea y procesador, buscando algún parámtero para lograr una optimiza-

ción (usulamente tiempo). Entre los algoritmos de mapeo/planificación conocidos se destaca el

AMTHA 28(De Giusti et al., 2009).

2.2.4. Algoritmo de Mapeo AMTHA

Es un algoritmo aplicado desde el gráfo generado por el modelo MPAHA 29. Se encarga de

asignar las tareas a cada procesador de la arquitectura minimizando los tiempos de ejecución.

Éste algoritmo debe proveer el orden en que cada tarea se asignará a cada procesador para su

ejecución (Planificador de tarea). AMTHA considera una arquitectura con un número limitado

de procesadores Heterogéneos (De Giusti et al., 2009).

El pseudo-código básico de asignación de este algoritmo es:

26En inglés, scheduler27En inglés, load balancer28Automatic Mapping Task on Heterogeneous Architectures29Model on Parallel Algorithms on Heterogeneous Architectures

35

1. Calcular el tiempo de ejecución de cada tarea.

2. Seleccionar la próxima tarea t para asignar.

3. Elegir el procesador p donde la tarea t debe ser asignada.

4. Asignar la tarea t (seleccionada en el paso 1) al procesador p (seleccionado en el paso 2).

5. Actualizar los tiempos de ejecución de las tareas y repetir los pasos anteriores.

36

Capítulo 3

Descripción del Problema

3.1. Sistema de tiempo real

Un sistema de tiempo real consiste en un conjunto Π de N tareas periódicas. Cada tarea τi

∈ Π está caracterizada por su período, Ti, el tiempo límite para ejecutarse, Di el peor tiempo de

ejecución, Ci, el tiempo de inicio (offset), φi, y una prioridad, Pi.

Π = {τi = (Ti,Di,Ci,φi,Pi)}

La unidad mínima de cómputo de una tarea τi es una acción J. Una tarea es un conjunto de

acciones similares que se repiten a lo largo del tiempo.

τi = Ji,1,Ji,2, ...,Ji,q

37

Se asume que:

τi,q = Ji,q

Figura 3.1: Se observa una acción Ji,0 de una tarea τi

En la figura 3.1 se observa la ejecución de una instancia de la tarea τi. Introduciendo con-

ceptos como Jitter 1, tiempo de activación 2, tiempo límite 3 y tiempo de respuesta 4.

3.2. Sistemas heterogéneos

Un sistema con multiprocesadores heterogéneos está compuesto por un conjunto Φ de tipos

de procesadores diferentes ϕx.

Φ = {ϕx,y,1 6 x > M,y > 0}

El subíndice x indica el tipo de procesador y el subíndice y indica la cantidad.

1Jitter, es el tiempo transcurrido desde que la instancia de la tarea esta lista para ser ejecutada y el comienzo de

la ejecución.2Tiempo de activación, es el instante en el que la instancia de la tarea pasa a estar lista para ser ejecutada.3Tiempo límite o deadline, es el instante en el que la instancia de la tarea deja de estar lista para ser ejecutada.4Tiempo de respuesta o response time es el tiempo que transcurre desde que la instancia de la tarea esta lista

para ser ejecutada y la finalización de la ejecución de la misma.

38

3.3. Sistema de tiempo real de tareas periódicas en procesa-

dores heterogéneos

Un sistema de tiempo real de tareas periódicas en procesadores heterogéneos es un sistema

compuesto por:

Un procesador ϕp ∈ Φ.

Un conjunto de tareas τ ∈ Π que se pueden ejecutar en ϕp.

Otro procesador ϕc ∈ Φ donde ϕc 6= ϕp.

Un conjunto de tareas τ ∈ Π que se pueden ejecutar en ϕc.

y sigue las condiciones que se especifican a continuación:

Cada tarea τi tiene asignada una prioridad. La tarea que tiene mayor frecuencia es la que

tiene mayor prioridad. Y la que tiene menor frecuencia es la que tiene menor prioridad.

Todas las tareas se pueden ejecutar en el procesador ϕp.

Algunas tareas τi pueden ser ejecutadas en el coprocesador ϕc.

Una vez que una instancia q representada por τi,q de una tarea τi inició su ejecución , solo

puede continuar en procesadores del mismo tipo.

Cada tarea deberá tener una definición para cada tipo de procesador en la que pueda ser

ejecutada.

39

3.4. Estructuras de datos usadas en un sistema

En primer lugar se debe guardar la información relacionada a cada una de las tareas. Cada

tarea se definirá con:

Su período, Ti

El tiempo límite para ejecutarse, Di

El peor tiempo de ejecución, Ci

El tiempo de inicio (offset), φi

Una prioridad, Pi

La instancia actual que está en ejecución q

Si la instancia actual q inició la ejecución

Una vez que una tarea inicia un periodo nuevo, genera una instancia de si misma. Esta

instancia debería ir a la lista de tareas listas para su ejecución (lista ordenada por prioridad).

3.5. Paso a paso de la planificación de tareas

1. El planificador se fija, en cada instante de tiempo t, si una tarea τi inicia un período nuevo

(una instancia nueva), en ese caso, τi,q debería agregarse al conjunto de tareas lista para

ejecutar. Esto significa que la instancia anterior τi,q−1 alcanzó a su tiempo de finalización.

Si la instancia τi,q−1 completó su ejecución. Entonces τi,q es agregada al conjunto

de tareas listas para ejecutarse.

Si la instancia τi,q−1 empezó su ejecución pero no la completó, entonces:

40

• Si se planifica con Aborto, la instancia τi,q−1 se aborta y la instancia τi,q es

agregada al conjunto de tareas listas para ejecutarse.

• Si se planifica con terminación tardía, la instancia τi,q se aborta y la instancia

τi,q−1 continua en ejecución o en espera para concluir su ejecución.

2. El planificador debe decidir que tarea τi se va a ejecutar en el instante t siguiente.

Si hay algún procesador libre, busca una tarea en la lista de tareas listas para ejecutar

y le asigna el procesador libre.

Si todos los procesadores se encuentran ocupados, entonces compara las tareas que

se encuentran en la lista de tareas listas para ejecutar y si encuentra una de mayor

prioridad, entonces realiza un cambio de contexto.

3. Ejecuta las tareas que se encuentran en los procesadores.

4. Vuelve al paso 1.

3.6. Mecanismos para la planificación de tareas

Los mecanismos para planificar las tareas son en sí la forma en que se le asignan las prio-

ridades a las tareas. Los más usados son:

Prioridades fijas (PF): A cada tarea se le asigna una prioridad al iniciar la ejecución y esta

no cambia. Para ello, se ordenan las tareas por su período T en orden creciente, y a cada

una se le asigna una prioridad.

Prioridades dinámicas (EDF): Inicialmente es igual a PF, pero a medida que avanza el

tiempo t, en cada instante se recalcula la prioridad.

Pi,q = Pi,q−1 (3.1)

41

3.7. Mecanismos para manejo de tareas no cumplidas por so-

brecarga

Cuando una tarea llega a su tiempo de finalización y no terminó la ejecución, el planificador

debe decidir que hacer con esa instancia. Los mecanismos más usados son:

Aborto: Abortar la instancia de la tarea en curso y darle lugar a la instancia nueva.

Terminación Tardía: Esperar a que la instancia termine su ejecución en algún momento y

abortar las instancias siguientes que se encuentren listas para ejecutar.

42

Capítulo 4

Solución propuesta

4.1. Simulador

El simulador implementado esta compuesto básicamente por tres secciones. La sección de

“Action”, la sección de “Configuration” y la sección de “Result”. Además contiene una barra

de menú desplegable con acciones sobre los datos del planificador (Import y Show).

En la figura 4.1, se observa la ventana principal de la herramienta donde se pueden distin-

guir fácilmente las secciones mencionadas.

4.1.1. Descripción del simulador

En ésta sección de detallará cada componente de la herramienta referenciado con un nú-

mero en la figura 4.2.

1. Representa la barra de menú de la herramienta, la cual se sub-divide en tres secciones

43

Figura 4.1: Ventana principal de la herramienta en su estado inicial

44

Figura 4.2: Descripción de la ventana principal de la herramienta en su estado inicial

45

“File”, “Processor” y “Task”.

2. Sección “File” del menú, contiene la acción que permite importar los procesadores y

tareas que serán utilizados en el planificador.

3. Sección “Processor” del menú, contiene la acción “Show”, que permite visualizar en una

ventana auxiliar los procesadores que serán utilizados por el simulador en la planificación.

4. Sección “Task” del menú, contiene la acción “Show”, que permite visualizar en una ven-

tana auxiliar las tareas que serán planificadas por el simulador.

5. Sección que contiene las principales acciones del simulador.

6. Acción “Run”, encargada de comenzar la simulación de la planificación con los paráme-

tros de configuración previamente seteados en la sección de configuración.

7. Acción de “Reset”, su principal función es limpiar todos los datos seteados y reiniciar la

herramienta a su estado inicial. Para que se ejecute esta acción es necesaria la confirma-

ción por parte del usuario.

8. Acción “Save Resume”, se encarga de almacenar en un archivo un resumen de la pla-

nificación previamente ejecutada. En el resumen se guardan las instancias fallidas y las

instancias finalizadas correctamente de cada tarea.

9. Sección de “Configuration”, contiene los parámetros que utiliza la planificación en su

ejecución.

10. “Priority” opción de configuración que determina que tipo de planificación por priorida-

des se utilizará en la simulación, pudiéndose seleccionar EDF (prioridades dinámicas) ó

PF (prioridades fijas).

11. “Deadline”, opción de configuración que determina la acción a realizar por el planificador

en caso de que la instancia de una tarea alcance su tiempo máximo de espera. Se puede

elegir entre 2 (dos) acciones a realizar, Aborto o Terminación Tardía.

46

12. “Instants of time”, opción de configuración que determina los instantes de tiempo que se

ejecutará el planificador.

13. Sección de resultado, en esta sección se muestra un resumen con el resultado de la plani-

ficación ejecutada.

14. Área donde se muestra el resumen de la planificación ejecutada. El resumen contiene la

cantidad de instancias que fallaron y la cantidad de instancias que finalizaron correcta-

mente y a que tarea pertenece cada instancia.

15. Save Details, acción que permite almacenar en un archivo el detalle (detallado por instante

de tiempo) de la planificación ejecutada y finalizada previamente.

4.1.2. Instrucciones para ejecutar una planificación

Para realizar una planificación utilizando el simulador, lo primero que se debe hacer es

importar un archivo (generado por la herramienta de generación de escenarios explicado en la

sección 4.3), el cual contenga la definición de las N tareas y los M procesadores que conforman

el sistema.

En la figura 4.3, se observa la estructura que debe cumplir el archivo a importar, para ser

aceptado por el simulador.

Para realizar la importación del archivo, se debe seleccionar la acción “Load Planning”, que

se encuentra dentro de la sección “File” de la barra de menú de la herramienta, luego se debe

seleccionar el archivo que se desea importar, si su formato es correcto se activarán las acciones

“Run” y las acciones de la barra de menú de la herramienta que se encontraban inactivas.

Una vez finalizada la importación del archivo, se deben elegir las opciones de configuración

que determinarán el comportamiento del planificador. Se debe seleccionar la opción “Priority”,

la cual por defecto se setea en “PF”, la opción “Deadline” que por defecto se setea en “Abort” y

47

Figura 4.3: Estructura que debe cumplir el archivo a importar

48

por último para finalizar la configuración se debe determinar la cantidad de instantes de tiempo

que se ejecutará el planificador, modificando la opción “Instants of time”, que por defecto es

225.000 ms.

Al finalizar con el seteo de las opciones de configuración del simulador, el mismo, estará

listo para comenzar la planificación de las tareas. Para esto, se debe presionar sobre el botón

“Run” (ver figura 4.4), el cual dará comienzo a la planificación de las N tareas en los M proce-

sadores del sistema.

Figura 4.4: Botón para comenzar la ejecución de la planificación

Cuando la planificación termine, en la sección “Result”, se mostrará un resumen con la

cantidad de instancias fallidas de cada tarea y la cantidad de instancias que finalizaron correc-

tamente, junto a qué tarea corresponde cada instancias fallida o finalizada correctamente.

El resumen de la planificación puede ser almacenado por el usuario en un archivo, utili-

zando la acción “Save Resume” (ver figura 4.5). Además, se podrá almacenar el detalle de la

planificación utilizando la acción “Save Details”.

Figura 4.5: Botón para almacenar un resumen de la planificación

49

4.2. Casos testigos

1. Al iniciar la ejecución de una planificación, todas las tareas se encuentran listas

para ser ejecutadas y todos los procesadores libres. Las tareas de mayor prioridad

ocupan los procesadores.

Para comprobar que al iniciar una planificación, las tareas de mayor prioridad son las que

toman control de los procesadores se define un conjunto de tareas (Cuadro 4.1) y procesa-

dores (Cuadro 4.2) y se realiza una planificación con un planificador por prioridades fijas

y si la instancia de una tarea alcanza su plazo máximo, aplica el aborto de la instancia que

lo alcanza.

Como se observa en la figura 4.6, en el instante 0 (cero) de tiempo de la planificación, las

tareas que toman control de los procesadores son T 5, T 1, T 7, T 4 y T 10 y permanecen

en la lista de tareas listas para ejecutar las tareas T 2, T 6, T 3, T 9 y T 8, las cuales tienen

menor prioridad que las tareas que se encuentran en los procesadores. Comprobando que

al iniciar la ejecución de una planificación y al estar todos los procesadores libres, las

tareas de mayor prioridad se ejecutan antes que las de menor prioridad.

Figura 4.6: Planificación PF ABORTO instante 0 (cero) de tiempo

50

Tarea T. Inicio T. Computo Periodo=Prioridad Compatibilidad

T 1 0 3 6 CPU-GPU

T 2 0 5 8 CPU

T 3 0 9 9 CPU

T 4 0 1 3 FPGA

T 5 0 3 3 CPU-GPU

T 6 0 5 8 FPGA-CPU

T 7 0 2 6 CPU-GPU

T 8 0 4 10 FPGA-GPU

T 9 0 6 9 FPGA-GPU

T 10 0 3 7 FPGA

Cuadro 4.1: Ejemplo 1 de definición de tareas

Procesador Tipo Clock

P1 CPU 2

P2 CPU 2

P3 GPU 1

P4 FPGA 3

P5 FPGA 3

Cuadro 4.2: Ejemplo 1 de definición de procesadores

51

2. Al ocuparse todos los procesadores, las tareas que están listas para ser ejecutadas y

no fueron asignadas a un procesador, deben esperar.

Para este caso, se utiliza la definición de tareas (Cuadro 4.1) y procesadores (Cuadro 4.2)

y se realiza una planificación con un planificador por prioridades fijas y si la instancia de

una tarea alcanza su plazo máximo, aplica el aborto de la instancia que lo alcanza.

Como se observa en la figura 4.6, en el instante 0 (cero) de tiempo de la planificación, las

tareas T 2, T 3, T 6, T 8 y T 9 están listas para ser ejecutadas pero todos los procesadores

se encuentran ocupados por tareas de mayor prioridad, es por eso que deben esperar para

ser ejecutadas en la lista de pendientes o listas para ejecutar.

A medida que transcurre el tiempo, el planificador consultará ésta lista para ir ejecutando

las tareas cuando sea posible.

Figura 4.7: Planificación PF ABORTO instante 2 (dos) y 3 (tres) de tiempo

3. Una tarea se encuentra en ejecución, pero llega una nueva tarea con mayor priori-

dad y lista para ser ejecutada. Se realiza un cambio de contexto.



52

una tarea alcanza su plazo máximo, aplica el aborto de la instancia que lo alcanza.

Como se observa en la figura 4.7, en el instante 3 (tres) de tiempo de la ejecución se

produce un cambio de contexto en el procesador id = 3 de tipo GPU, el cual en el instante

2 (dos) de tiempo ejecuta la tarea T 8 cuya prioridad es 10 (diez), pero en el instante 3

(tres) de tiempo, la tarea T 8 es desalojada del procesador y es colocada en la lista de

tareas listas para ejecutar y en el procesador id = 3 de tipo GPU se ejecuta la tarea T 5

cuya prioridad es 3 (tres) como la prioridad de T 5 es mayor que la prioridad de T 8, se

produce un cambio de contexto.

La tarea T 5, puede ser ejecutada en los procesadores tipo GPU y CPU, pero en el instante

3 (tres) de tiempo, en los procesadores tipo CPU, se ejecutan las tareas T 2 y T 3 las cuales

tienen mayor prioridad que la tarea T 8 (Cuadro 4.2).

4. Una tarea desalojada de un procesador producto de un cambio de contexto, debe

conservar el tipo de procesador en el que se comenzó a ejecutar.



una tarea alcanza su plazo máximo aplica el aborto de la instancia que lo alcanza.

Como se observa en la figura 4.8, en el instante 3 (tres) de tiempo en la ejecución se

produce un cambio de contexto, la tarea T 8 es desalojada del procesador y se coloca en

la lista de tareas lista para ejecutar, conservando el tipo de procesador en el que comenzó

a ejecutarse para continuar su ejecución solo en un procesador compatible.

En este caso y como se observa en la figura 4.7, la tarea T 8 conserva el tipo GPU ya que

en el instante 2 (dos) de tiempo se encontraba ejecutándose en el procesador id = 3 de

tipo GPU (figura 4.7)

5. Una tarea desalojada de un procesador producto de un cambio de contexto, vuelve

a tomar control de un procesador del mismo tipo donde comenzó su ejecución para

continuar con la misma.


53

Figura 4.8: Planificación PF ABORTO instante 3 (tres) de tiempo



Como se observa en la figura 4.9, la tarea T 3 se ejecuta en el instante 5 (cinco) de tiempo

en el procesador id = 2 de tipo CPU, pero en el instante siguiente la tarea T 7 provoca

un cambio de contexto desalojando a la tarea T 3. La tarea T 7 se ejecuta y finaliza su

ejecución en el instante 6 (seis) de tiempo y al finalizar libera al procesador id = 2 el cual

es ocupado en el instante siguiente de tiempo nuevamente por la tarea T 3 para continuar

su ejecución.

6. Una tarea lista para ser ejecutada, espera aún habiendo procesadores libres, si la

tarea no puede ser ejecutada en los procesadores disponibles.




Como se observa en la figura 4.18, en el instante 4 (cuatro) y 5 (cinco) de tiempo, la tarea

T 8 se encuentra en la lista de tareas listas para ser ejecutadas y los procesadores id = 4

y id = 5 se encuentran libres (ambos de tipo FPGA). Debido a que la tarea T 8 comenzó

a ser ejecutada en un procesador de tipo GPU, en los instantes 4 (cuatro) y 5 (cinco) de

tiempo, no es compatible con los procesadores id = 4 y id = 5 ambos de tipo FPGA y

aún estando disponible nos los puede ocupar para continuar con su ejecución

54

Figura 4.9: Planificación PF ABORTO instante 5 (cinco), 6 (seis) y 7 (siete) de tiempo

55

7. Una tarea crea una nueva instancia de la misma, al cumplirse su periodo y la ins-

tancia anterior finalizó correctamente.



una tarea alcanza su plazo máximo aplica el aborto de la instancia siguiente (finalización

tardía).

Como se observa en la figura 4.10, en el instante 5 (cinco) de tiempo la tarea T 5 que se

ejecuta en el procesador id = 3 de tipo GPU, finaliza correctamente la ejecución de la

instancia 2 (dos) y en el instante siguiente de tiempo, la tarea T 5 comienza la ejecución

de la instancia 3 (tres) en el procesador id = 1 de tipo CPU.

Como se observa en el ejemplo anterior la tarea T 5 tiene un periodo de 3 (tres), es decir,

que en el instante 6 (seis) de tiempo la tarea comienza la ejecución de una nueva instancia

en el instante anterior de tiempo finaliza la ejecución de la instancia anterior.

Figura 4.10: Planificación PF FINALIZACIÓN TARDÍA instante 5 (cinco) y 6 (seis) de tiempo

8. Una tarea retiene a un procesador y se mantiene en ejecución hasta que la mis-

ma complete su tiempo de cómputo, siempre que no haya una tarea que genere un

cambio de contexto con la misma.


56



Como se observa en la figura 4.19, la tarea T 9 que se ejecuta en el procesador id = 5 de

tipo FPGA lo retiene en los instantes 1 (uno) y 2 (dos) de tiempo y se ejecuta la tarea

hasta finalizar correctamente. Como se puede observar en los instantes de tiempo en los

que se ejecuta la tarea, esta retiene al procesador y en dichos instantes no hay ninguna

tarea disponible para ejecutar que produzca un cambio de contexto con T 9.

9. Una tarea finaliza correctamente su ejecución, al completar su tiempo de cómputo

y no alcanzar su plazo máximo de espera.




Como se observa en la figura 4.19, la tarea T 9 que se ejecuta en el procesador id = 5

de tipo FPGA en los instantes 1 (uno) y 2 (dos) de tiempo, finaliza correctamente su

ejecución en el instante 2 (dos) de tiempo antes de alcanzar su plazo máximo, que para la

instancia que se esta ejecutandosería el instante 9 (nueve) de tiempo. Como el periodo de

la tarea T 9 es T = 9, en el instante 10 (diez) de tiempo se comienza a ejecutar la siguiente

instancia de tiempo.

10. Una tarea alcanza su plazo máximo de espera y debe abortar la ejecución de la

instancia actual.




Como se observa en la figura 4.11, la tarea T 8 alcanza su plazo máximo de espera, por lo

que debe abortar la instancia actual de la misma, en éste caso se debe abortar la instancia

1 (uno) de la tarea.

La tarea T 8 comenzó a ejecutarse en el instante 2 (dos) de tiempo, en el procesador

57

id = 3 de tipo GPU como se puede observar en la figura 4.7, pero se produjo un cambio

de contexto en el instante 3 (tres) de tiempo y fue desalojada del procesador id = 3 de

tipo GPU por la tarea T 5.

T 8 no recupero el procesador para continuar con su ejecución y de esta manera no finalizó

correctamente, al alcanzar su plazo máximo de espera sin haber terminado su ejecución,

se produce el aborto de esa instancia de la tarea.

El aborto de la instancia 1 (uno) de T 8 se produce al finalizar el instante 9 (nueve) de

tiempo y comenzar el instante 10 (diez) de tiempo.

Figura 4.11: Planificación PF ABORTO instante 9 (nueve) y 10 (diez) de tiempo

11. Al alcanzar una tarea su plazo máximo de espera y abortar la instancia actual, debe

aparecer lista para ejecutarse la instancia siguiente de la tarea.




Como se observa en la figura 4.11, la tarea T 8 alcanza su plazo máximo de espera, por lo

que debe abortar la instancia actual de la misma, en éste caso se debe abortar la instancia

58

1 (uno) de la tarea.

Al completarse el periodo de T 8 en el instante 10 (diez) de tiempo, la nueva instancia (en

este caso instancia 2 (dos) de la tarea) se encuentra disponible para ejecutarse y como se

observa en la figura 4.11, en el instante 10 (diez) de tiempo la instancia 2 (dos) de la tarea

T 8 se encuentra ejecutándose en el procesador id = 4 de tipo FPGA.

12. Una tarea alcanza su plazo máximo de espera y debe abortar la ejecución de la

instancia siguiente de la tarea y darle más tiempo a la instancia actual para que

termine su ejecución.




tardía).

Como se observa en la figura 4.12, al finalizar la instancia 9 (nueve) de tiempo y comenzar

la instancia 10 (diez) de tiempo, la tarea T 8 alcanzo su plazo máximo de espera y debe

abortar, pero en este caso no se aborta la instancia actual que se esta ejecutando (en este

caso instancia 1 (uno)) sino que se aborta la instancia siguiente (en este caso instancia 2

(dos) de la tarea) ya que el planificador es con finalización tardía.

Al mantener la instancia que se estaba ejecutando (instancia 1 (uno) de la tarea), se debe

actualizar el plazo máximo de espera para dicha instancia, ampliando el plazo con el valor

de la instancia que se aborto, como se ve en la figura 4.12 en el instante 10 (diez) de tiempo

la tarea T 8 modifica el plazo máximo de espera de 10 (diez) a 20 (veinte), como se observa

en [n = t8,c = 4,T = 20, phi = 0, p = 10, i = 1,cr = 1ProcType = GPU ], ampliando su

plazo máximo y de esta manera continuar en la espera para poder ser ejecutada.

13. Una tarea puede producir que se aborten más de una instancia siguiente a la que se

encuentra en ejecución si no finaliza y alcanza el plazo máximo de espera.



59

Figura 4.12: Planificación PF FINALIZACIÓN TARDÍA instante 9 (nueve) y 10 (diez) de tiem-

po


tardía).

Como se observa en la figura 4.12, la tarea T 8 alcanza su plazo máximo y produce el

aborto de la instancia siguiente de la tarea, en ese caso se aborta la instancia 2 (dos) ya

que se encuentra en ejecución o espera la instancia 1 (uno) de la tarea.

Al producirse el aborto de la instancia 2 (dos), la instancia 1 (uno) aumenta el plazo

máximo de espera a 20 (veinte), pero dada la planificación y el conjunto de tareas defi-

nidos, éste nuevo plazo máximo de espera no es suficiente para finalizar la ejecución de

la instancia 1 (uno) de la tarea, y como se observa en la figura 4.13 se alcanza el nuevo

plazo máximo de espera de la instancia y se vuelve a producir el aborto de una instancia

siguiente, en este caso se debe abortar la instancia 3 (tres) de la tarea.

La instancia 1 (uno) de la tarea T 8 vuelve a modificar su plazo máximo de espera para

continuar ejecutándose o a la espera de poder hacerlo ([n = t8,c = 4,T = 30, phi = 0, p =

10, i = 1,cr = 1ProcType = GPU ]).

60

14. Una tarea que generó el aborto de una instancia siguiente finaliza su ejecución antes

de alcanzar el nuevo plazo máximo.




tardía).

Como se observa en la figura 4.14, la tarea T 4 alcanza su plazo máximo de espera al

finalizar el instante 5 (cinco) de tiempo, al comienzo del instante 6 (seis) de tiempo se

produce el aborto de la instancia siguiente a la que se esta ejecutando, en este caso se

aborta la instancia 2 (dos) de la tarea T 4 y en el instante 7 (siete) de tiempo, la instancia

1 (uno) de la tarea T 4 finaliza su ejecución correctamente.

Figura 4.13: Planificación PF FINALIZACIÓN TARDÍA instante 19 (diecinueve) y 20 (veinte)

de tiempo

15. Al finalizar la ejecución y cumplirse el periodo de una tarea que produjo el aborto

de la instancia siguiente de la misma, la nueva instancia a ejecutar debe considerar

a la/s instancia/s abortada/s.


61


T 1 0 3 4 CPU-GPU

T 2 0 5 5 CPU

T 3 0 2 4 CPU

T 4 0 4 6 GPU


Procesador Tipo Clock

P1 CPU 2

P2 CPU 2

P3 GPU 1

Cuadro 4.4: Ejemplo 2 de definición de procesadores

Figura 4.14: Planificación PF FINALIZACIÓN TARDÍA instante 5 (cinco), 6 (seis) y 7 (siete)

de tiempo

62



tardía).

Como se observa en la figura 4.14, la tarea T 4 alcanza su plazo máximo de espera y

produce el aborto de la instancia siguiente a la que se esta ejecutando, luego, en el instante

7 (siete) de tiempo la instancia 1 (uno) de la tarea T 4 finaliza su ejecución correctamente.

Finalmente, como se observa en la figura 4.15, una nueva instancia de la tarea T 8 esta

lista para ser ejecutada y como se puede observar en la figura, la instancia que espera

para ser ejecuta, es la instancia 3 (tres), considerando que la instancia 1 (uno) finalizo

correctamente y la 2 (dos) fue abortada.

Figura 4.15: Planificación PF FINALIZACIÓN TARDÍA instante 12 (doce) de tiempo

16. Una tarea conserva su prioridad fija durante toda su ejecución.




Como se observa en la figura 4.16, la tarea T 3 que se ejecuta en el procesador id = 2 de

tipo CPU, conserva en cada instante de tiempo la prioridad fija, la cual se mantiene en 9

(nueve).

Al ser una planificación por prioridades fijas las prioridades de cada tarea se mantienen

igual para la ejecución de cada instancia de la misma.

63

Figura 4.16: Planificación PF ABORTO instante 3 (tres), 4 (cuatro) y 5 (cinco) de tiempo

17. Una tarea varía su prioridad durante su ejecución en cada instante de tiempo. La

prioridad de la tarea disminuye en uno para que su prioridad aumente. Planificación

con prioridades dinámicas.

Para este caso, se utiliza la definición de tareas (Cuadro 4.1) y procesadores (Cuadro

4.2) y se realiza una planificación con un planificador por prioridades dinámicas y si la

instancia de una tarea alcanza su plazo máximo aplica el aborto de la instancia siguiente

(finalización tardía).

Como se observa en la figura 4.17, por cada instante de tiempo que pasa la prioridad de

las tareas que se encuentran en ejecución o en espera de un procesador para poder ser

ejecutadas, se disminuye en 1 (uno).

Por ejemplo, si tomamos la tarea T 2, que en el instante 0 (cero) de tiempo se encuentra

esperando para ser ejecutada, se puede observar que la misma tiene en dicho instante de

tiempo una prioridad p = 8, luego en el instante 1 (uno) de tiempo la misma tarea T 2 que

permanece a la espera para ser ejecutada modificó su prioridad y es p = 7.

Lo mismo ocurre con tareas que se encuentran en ejecución en un procesador, con cada

64

instante de tiempo que transcurre, su prioridad se disminuye en uno, por ejemplo la tarea

T 5 que se encuentra en ejecución también modifica su prioridad, como se puede observar

en la figura 4.17.

Figura 4.17: Planificación EDF FINALIZACIÓN TARDÍA instante 0 (cero), 1 (uno) y 2 (dos)

de tiempo

18. Un procesador se mantiene libre si no hay ninguna tarea lista para ejecutarse com-

patible con él.




65

Como se observa en la figura 4.18, en el instante 4 (cuatro) y 5 (cinco) de tiempo, tanto

el procesador id = 4 y el procesador id = 5 ambos de tipo FPGA, se encuentran libres

aunque hay tareas esperando para ser ejecutadas, pero no son compatibles con los proce-

sadores.

En ambos instantes de tiempo, se observa que la tarea T 8 espera para ser ejecutada, la

misma es compatible con los procesadores FPGA, pero comenzó a ser ejecutada en un

procesador de tipo GPU, en el instante 2 (dos) de tiempo, por lo que no puede continuar

su ejecución en un procesador de tipo FPGA.

Figura 4.18: Planificación PF ABORTO instante 4 (cuatro) y 5 (cinco) de tiempo

19. Una tarea libera al procesador cuando la misma completa su ejecución correcta-

mente.




Como se observa en la figura 4.19, la tarea T 9 comienza su ejecución en el procesador

id = 5 de tipo FPGA en el instante 1 (uno) de tiempo, en el instante siguiente continua

con su ejecución en el mismo procesador y finaliza su ejecución en el instante 2 (dos) de

tiempo, como se puede observar en el instante 3 (tres) de tiempo, la tarea T 9 ya no ocupa

el procesador id = 5 de tipo FPGA, el mismo se encuentra libre en ese instante de tiempo

debido a que no hay ninguna tarea compatible para ejecutar.

66

Figura 4.19: Planificación PF ABORTO instante 1 (uno), 2 (dos) y 3 (tres) de tiempo

67


T 1 0 2 5 CPU-GPU

T 2 0 3 3 CPU

T 3 0 3 4 CPU-GPU

T 4 0 5 5 GPU


20. Una tarea libera al procesador cuando alcanza su plazo máximo, dejándolo libre

para otra tarea o para la nueva instancia de la misma tarea.




Como se observa en la figura 4.20, la instancia 1 (uno) de la tarea T 4 alcanza su plazo

máximo de espera en el instante 4 (cuatro) de tiempo, en el cual se encuentra ejecután-

dose en el procesador id = 3 de tipo GPU, al alcanzar su plazo máximo de espera, la

instancia de la tarea es abortada y la tarea libera al procesador para que otra tarea o la

nueva instancia de T 4 se ejecuten en el próximo instante de tiempo.

21. Una tarea continua su ejecución en un procesador si alcanza su plazo máximo de

espera y produce el aborto de la instancia siguiente, continúa ejecutándose mientras

ninguna tarea lista para ser ejecutada produzca un cambio de contexto.




tardía).

Como se observa en la figura 4.21, la instancia 1 (uno) de la tarea T 4 que se encuentra

ejecutandose en el procesador id = 3 de tipo GPU, alcanza su plazo máximo de espera en

el instante 4 (cuatro) de tiempo, produciendo el aborto de la instancia siguiente (en este

68

Figura 4.20: Planificación PF ABORTO instante 4 (cuatro) y 5 (cinco) de tiempo

caso instancia 2 (dos) de la tarea). Al modificarse el plazo máximo de espera y no haber

ninguna tarea que requiera al procesador id = 3 de tipo GPU, la instancia 1 (uno) de T 4

conserva el procesador en el instante 5 (cinco) de tiempo para continuar con su ejecución.

Figura 4.21: Planificación PF FINALIZACIÓN TARDÍA instante 4 (cuatro) y 5 (cinco) de

tiempo

69

22. El periodo de una tarea se debe mantener fijo durante toda su ejecución, para cada

instancia de la misma.




Como se observa en la figura 4.22, la tarea T 4 se encuentra lista para ser ejecutada en

los instantes 0 (cero), 3 (tres), 6 (seis) y 9 (nueve) de tiempo. Como se puede observar la

tarea T 4 esta lista para ser ejecutada cada 3 instantes de tiempo, lo que es correcto ya que

su periodo es de 3 (tres). Como se observa en la siguiente definición [n = t4,c = 1,T =

3, phi = 0, p = 3, i = 1,cr = 0ProcType = FPGA], donde T = 3 representa el periodo de

la tarea T 4 .

23. El tiempo de cómputo de una tarea debe mantenerse fijo durante toda su ejecución,

para cada instancia de la misma.




Como se observa en la figura 4.22, la tarea T 4 en cada instante de tiempo en que se en-

cuentra lista para ser ejecutada, conserva en cada instancia el mismo tiempo de cómputo.

La tarea T 4 como se observa en la figura representado con [n = t4,c = 1,T = 3, phi =

0, p = 3, i = 1,cr = 0ProcType = FPGA], donde c = 1 representa el tiempo de cómputo

de T 4 se repite en cada una de las instancias y cr = 0 el el tiempo de cómputo realizado,

cuando cr = c la tarea finaliza su ejecución.

24. El cómputo realizado en un instante de tiempo en una instancia de una tarea depen-

derá del tipo de procesador en el que se está ejecutando.




70

Figura 4.22: Planificación PF ABORTO periodo y cómputo de una tarea

71

Como se observa en la figura 4.8, los procesadores id = 1, id = 2, id = 3 y id = 4 se en-

cuentran ocupados ejecutando tareas, pero estos procesadores no todos tienen la misma

velocidad, varia el clock de cada tipo de procesador, por ejemplo, el clock de un procesa-

dor de tipo CPU es de 2 (dos) mientras que el clock de un procesador de tipo FPGA es

de 3 (tres), esta diferencia hace que el cómputo realizado por cada procesador no sea el

mismo.

El cómputo realizado en cada instante de tiempo esta relacionado con el clock del proce-

sador en que se ejecuta, es así, que como se ve en la figura 4.8, en el procesador id = 1 de

tipo CPU se ejecuta la tarea T 2 y en ese instante de tiempo el cómputo realizado es de 2

(dos), mientras que en el procesador id = 4 de tipo FPGA en el mismo instante se ejecuta

la tarea T 4 y el cómputo realizado es de 3 (tres), mientras que en el procesador id = 3 de

tipo GPU se ejecuta la tarea T 5 y el cómputo realizado en el instante de tiempo para esta

tarea es de 1 (uno).

Como queda demostrado en este caso, el tiempo de cómputo realizado por cada tarea en

cada instante de tiempo depende del clock del procesador donde es ejecutada.

25. Al finalizar la planificación se debe mostrar correctamente la cantidad de instancias

que alcanzaron su plazo máximo, detallado por tareas.




Se realizó una planificación con 20 (veinte) instancias de tiempo, y como se puede obser-

var en la figura 4.23, al final del detalle de la planificación en cada instante de tiempo, se

presenta un resumen con los resultados de la cantidad de instancias que fallaron y a que

tarea pertenece cada una de las instancias que fallaron.

En el caso del ejemplo, se ver que fallaron la instancia 1 (uno) de la tarea T 8 y la instancia

2 (dos) de la tarea T 3.

72

Figura 4.23: Detalle de las instancias que fallaron en la planificación PF y ABORTO

26. Al finalizar la planificación se debe mostrar correctamente la cantidad de instancias

que finalizaron correctamente detallado por tareas.




Se realizó una planificación con 20 (veinte) instancias de tiempo, y como se puede ob-

servar en la figura 4.24 al final del detalle de la planificación en cada instante de tiempo,

se presenta un resumen con los resultados de la cantidad de instancias que finalizaron

correctamente y a que tarea pertenece cada una de las instancias.

En el caso del ejemplo, se ve que finalizaron correctamente 36 (treinta y seis) instancias

pertenecientes a las 10 (diez) tareas definidas.

4.3. Generación de escenarios

Para testear el simulador, es necesario la generación de diferentes escenarios representati-

vos en los cuales se definen n tareas a planificar en m procesadores. El FU de los escenarios

generados deberá ser mayor o igual a 0,2 y menor o igual a 1,6; Éstos valores máximos y

mínimos son definidos previamente en el archivo generador.c.

Para llevar a cabo la función de generación de escenario, se utiliza una herramienta, la

cual esta formada por 2 (dos) archivos escritos en el lenguaje c (generador.c y definiciones.c),

en los cuales se detallan las funciones para la generación de los escenarios, y un archivo bash

(generador.sh), el cual se utilizará para correr el generador.

73

Figura 4.24: Detalle de las instancias que finalizaron correctamente en la planificación PF y

ABORTO

74

Tipo Clock

CPU 1

GPU 4

FPGA 7

Cuadro 4.6: Tipos de procesadores y sus clocks

Tipo Cantidad

CPU de 1 a 3

GPU de 0 a 2

FPGA de 0 a 1

Cuadro 4.7: Cantidad de procesadores de cada tipo

En el archivo generador.c, se definen los tipos de procesadores que se utilizarán en la

planificación, a partir de ellos, se tomará un tipo de procesador como base para la generación de

las tareas, las cuales, serán ejecutables en el/los procesadores del tipo elegido como base. Éste

tipo de procesador, debe tener un clock igual a 1 (uno).

En el archivo generador.c, se definen por defecto, 3 (tres) tipos de procesadores con sus

respectivos clocks (ver cuadro 4.6, en el que se muestra la definición de los procesadores).

Como se puede observar en la cuadro 4.6, el procesador de tipo CPU tiene un clock igual a 1

(uno), en ese caso, éste tipo de procesador es el que se toma como referencia para la generación

de las tareas y el cálculo del FU .

Otro punto a definir, es la cantidad de procesadores de cada tipo que tendrá el sistema. Para

ésto, se utiliza una función que determina dicha cantidad de manera aleatoria, considerando que

debe existir al menos 1 (un) procesador del tipo que se tome como base para la generación. Por

defecto se define en el archivo generador.c, la cantidad de procesadores de cada tipo, como se

muestra en el cuadro 4.7.

75

Id Clock TipoProc

0 1 CPU

1 1 CPU

2 1 CPU

3 4 GPU

4 7 FPGA

Cuadro 4.8: Ejemplo de generación de 5 (cinco) procesadores

Considerando las definiciones del cuadro 4.7, se deduce que la cantidad de procesadores

del sistema, estará determinada por la suma total de la cantidad de procesadores de cada tipo.

Con lo cual podemos distinguir dos escenarios extremos, uno con la cantidad mínima de proce-

sadores, con sólo 1 (un) procesador y otro con la cantidad máxima de procesadores con 6 (seis)

procesadores. En la cuadro 4.8, se puede observar, la definición de un conjunto de procesadores

que componen un sistema generado por la herramienta.

Una vez definido los tipos de procesadores y la cantidad de cada tipo, comienza la gene-

ración de las n tareas que deberán ser planificadas, otorgándoles de forma aleatoria un periodo

que va entre 400 (cuatrocientos) y 7000 (siete mil) instantes de tiempo (éstos valores son confi-

gurables en el archivo generador.c) y un tiempo de computo.

Las n tareas que se generen, deben cumplir con los FU especificados al inicio. Para calcular

el FU se utiliza la siguiente ecuación:

FU = Σ((Ci/Ti)/CantProcBase) (4.1)

Donde i representa a cada tarea, Ci los tiempos de computo, Ti los periodos y CantProcBase

cantidad de procesadores del tipo usado como base.

La cantidad de tareas que se deben generar, esta relacionada con la cantidad de procesado-

76

Tipo Cantidad de procesadores Cantidad de tareas

CPU 1 10

CPU 2 ó 3 20

Cuadro 4.9: Cantidad de tareas

res del tipo que se utilice como base en la generación. Considerando el cuadro 4.6, el procesador

que se utiliza por defecto es el de tipo CPU, entonces, la cantidad de tareas dependerá de la can-

tidad de procesadores de tipo CPU que se generen. En el cuadro 4.9 se define la relación por

defecto entre la cantidad de procesadores y la cantidad de tareas a generar.

Por último, se define con que tipos de procesadores será compatible cada tarea, conside-

rando que toda tarea será ejecutable en los procesadores del tipo que se utilizó como base. Ésta

asignación, se realiza de forma aleatoria, definiendo la cantidad de tipos de procesadores con

los que será compatible una tarea t y cuales serán esos tipos de procesadores.

En la cuadro 4.10, se puede observar, la definición de un conjunto de tareas que componen

un sistema generado por la herramienta.

Para realizar la generación de escenarios se debe ejecutar el archivo generador.sh, el cual se

encarga de crear la carpeta que contendrá los archivos generados del escenario. La nomeclatura

utilizada para la carpeta y los archivos es dinámica y se obtiene del momento exacto (fecha) en

que se ejecuta el generador.

El archivo generador.sh permite además, realizar varios ciclos de generación de escenarios

en una misma ejecución.

77

Name Computo Periodo Inicio TiposProc

t0 297 423 0 CPU

t1 97 571 0 FPGA-GPU-CPU


t3 204 1544 0 CPU

t4 194 1770 0 CPU

t5 438 1958 0 GPU-CPU

t6 957 2019 0 GPU-CPU

t7 61 2178 0 CPU


t9 1284 3061 0 FPGA-CPU

t10 521 3354 0 CPU

t11 1161 3490 0 GPU-CPU

t12 1881 3568 0 FPGA-CPU

t13 221 4234 0 CPU

t14 33 4252 0 GPU-CPU

t15 1183 4375 0 FPGA-GPU-CPU

t16 519 5575 0 CPU


t18 1157 6174 0 FPGA-CPU

t19 467 6425 0 FPGA-CPU

Cuadro 4.10: Ejemplo de generación de 20 (veinte) tareas con FU=1.5

78

Escenario Cantidad de escenarios Cantidad de procesadores Cantidad de tareas

Escenario 1 15 1 (CPU) 10

Escenario 2 15 4 (3 CPU + 1 GPU) 20

Escenario 3 15 2 (1 CPU + 1 GPU) 10

Escenario 4 15 5 (3 CPU + 1 GPU + 1 FPGA) 20

Cuadro 4.11: Descripción de los escenarios de testeo

4.3.1. Escenarios generados para testeo

Para el testeo del simulador, fueron utilizados cuatro conjuntos de escenarios compuestos

por quince escenarios cada uno. Los cuales se componen de un conjunto de procesadores y un

conjunto de tareas que cumplen con la condición de que su FU es mayor o igual a 0,2 y menor

o igual a 1,6. En el cuadro 4.11 se realiza una descripción de los escenarios de testeo indicando

la cantidad de procesadores y tareas que lo componen.

4.3.2. Resultados de los escenarios generados para testeo

En esta sección, se detallaran los resultados obtenidos al realizar las planificaciones de los

escenarios generados para realizar el testeo del simulador utilizando las diferentes combina-

ciones de algoritmos de planificación y acciones al llegar al tiempo máximo de espera de una

instancia.

En el cuadro 4.12, se detallan los resultados de la planificación del Escenario 1 (ver ca-

racterísticas en el cuadro 4.11), utilizando planificación por prioridades fijas (PF) y Aborto al

alcanzar una instancia el tiempo máximo de espera.

En el cuadro 4.13, se detallan los resultados de la planificación del Escenario 1 (ver carac-

terísticas en el cuadro 4.11), utilizando planificación por prioridades fijas (PF) y terminación

79

FU Instancias correctas Instancias incorrectas Total de instancias

0,2 1122 0 1122

0,3 1122 0 1122

0,4 1122 0 1122

0,5 1121 0 1121

0,6 1122 0 1122

0,7 1120 0 1120

0,8 1119 0 1119

0,9 1117 2 1119

1,0 1077 41 1118

1,1 1045 73 1118

1,2 1083 34 1117

1,3 1031 86 1117

1,4 1039 75 1114

1,5 984 133 1117

1,6 762 352 1114

Cuadro 4.12: Resultados planificación escenario 1 con PF y Aborto

80


0,2 1122 0 1122

0,3 1122 0 1122

0,4 1122 0 1122

0,5 1121 0 1121

0,6 1122 0 1122

0,7 1120 0 1120

0,8 1119 0 1119

0,9 1118 1 1119

1,0 1092 26 1118

1,1 1088 30 1118

1,2 1094 23 1117

1,3 1052 65 1117

1,4 1050 65 1115

1,5 1021 96 1117

1,6 788 326 1114

Cuadro 4.13: Resultados planificación escenario 1 con PF y Terminación Tardía

tardía al alcanzar una instancia el tiempo máximo de espera.


terísticas en el cuadro 4.11), utilizando planificación por prioridades dinámicas (EDF) y aborto

al alcanzar una instancia el tiempo máximo de espera.


racterísticas en el cuadro 4.11), utilizando planificación por prioridades dinámicas (EDF) y

terminación tardía al alcanzar una instancia el tiempo máximo de espera.


81


0,2 1122 0 1122

0,3 1122 0 1122

0,4 1122 0 1122

0,5 1121 0 1121

0,6 1122 0 1122

0,7 1120 0 1120

0,8 1119 0 1119

0,9 1119 0 1119

1,0 1035 80 1115

1,1 1038 76 1114

1,2 1030 86 1116

1,3 968 147 1115

1,4 916 197 1113

1,5 875 239 1114

1,6 827 287 1114

Cuadro 4.14: Resultados planificación escenario 1 con EDF y Aborto

82


0,2 1122 0 1122

0,3 1122 0 1122

0,4 1122 0 1122

0,5 1121 0 1121

0,6 1122 0 1122

0,7 1120 0 1120

0,8 1119 0 1119

0,9 1119 0 1119

1,0 1092 25 1117

1,1 1047 67 1114

1,2 1018 99 1117

1,3 966 150 1116

1,4 839 278 1117

1,5 831 284 1115

1,6 749 367 1116

Cuadro 4.15: Resultados planificación escenario 1 con EDF y Terminación Tardía

83


0,2 1497 0 1497

0,3 1497 0 1497

0,4 1496 0 1496

0,5 1495 0 1495

0,6 1497 0 1497

0,7 1497 0 1497

0,8 1496 0 1496

0,9 1494 0 1494

1,0 1493 1 1494

1,1 1489 3 1492

1,2 1493 0 1493

1,3 1446 46 1492

1,4 1427 65 1492

1,5 1437 57 1494

1,6 1349 140 1489


terísticas en el cuadro 4.11), utilizando planificación por prioridades fijas (PF) y aborto al llegar








84


0,2 1497 0 1497

0,3 1497 0 1497

0,4 1496 0 1496

0,5 1495 0 1495

0,6 1497 0 1497

0,7 1497 0 1497

0,8 1496 0 1496

0,9 1494 0 1494

1,0 1493 1 1494

1,1 1489 3 1492

1,2 1493 0 1493

1,3 1460 32 1492

1,4 1458 35 1493

1,5 1445 49 1494

1,6 1400 89 1489


85


0,2 1497 0 1497

0,3 1497 0 1497

0,4 1496 0 1496

0,5 1495 0 1495

0,6 1497 0 1497

0,7 1497 0 1497

0,8 1496 0 1496

0,9 1494 0 1494

1,0 1494 0 1494

1,1 1493 0 1493

1,2 1493 0 1493

1,3 1487 4 1491

1,4 1468 25 1493

1,5 1470 23 1493

1,6 1386 100 1486


86


0,2 1497 0 1497

0,3 1497 0 1497

0,4 1496 0 1496

0,5 1495 0 1495

0,6 1497 0 1497

0,7 1497 0 1497

0,8 1496 0 1496

0,9 1494 0 1494

1,0 1494 0 1494

1,1 1493 0 1493

1,2 1493 0 1493

1,3 1487 4 1491

1,4 1477 16 1493

1,5 1469 24 1493

1,6 1437 51 1488






racterísticas en el cuadro 4.11), utilizando planificación por prioridades fijas (PF) y aborto al





87


0,2 871 0 871

0,3 871 0 871

0,4 871 0 871

0,5 871 0 871

0,6 871 0 871

0,7 871 0 871

0,8 870 0 870

0,9 870 0 870

1,0 870 0 870

1,1 871 0 871

1,2 870 0 870

1,3 832 38 870

1,4 697 169 866

1,5 799 70 869

1,6 831 38 869


88


0,2 871 0 871

0,3 871 0 871

0,4 871 0 871

0,5 871 0 871

0,6 871 0 871

0,7 871 0 871

0,8 870 0 870

0,9 870 0 870

1,0 870 0 870

1,1 871 0 871

1,2 870 0 870

1,3 848 22 870

1,4 755 113 868

1,5 822 47 869

1,6 850 19 869


89


0,2 871 0 871

0,3 871 0 871

0,4 871 0 871

0,5 871 0 871

0,6 871 0 871

0,7 871 0 871

0,8 870 0 870

0,9 870 0 870

1,0 870 0 870

1,1 871 0 871

1,2 870 0 870

1,3 779 86 865

1,4 723 141 864

1,5 774 90 864

1,6 807 60 867









racterísticas en el cuadro 4.11), utilizando planificación por prioridades fijas (PF) y aborto al


90


0,2 871 0 871

0,3 871 0 871

0,4 871 0 871

0,5 871 0 871

0,6 871 0 871

0,7 871 0 871

0,8 870 0 870

0,9 870 0 870

1,0 870 0 870

1,1 871 0 871

1,2 870 0 870

1,3 808 62 870

1,4 805 59 864

1,5 785 83 868

1,6 831 37 868


91


0,2 2531 0 2531

0,3 2531 0 2531

0,4 2531 0 2531

0,5 2528 0 2528

0,6 2530 0 2530

0,7 2530 0 2530

0,8 2528 0 2528

0,9 2529 0 2529

1,0 2528 0 2528

1,1 2525 1 2526

1,2 2528 0 2528

1,3 2529 0 2529

1,4 2527 2 2529

1,5 2528 1 2529

1,6 2523 3 2526


92


0,2 2531 0 2531

0,3 2531 0 2531

0,4 2531 0 2531

0,5 2528 0 2528

0,6 2530 0 2530

0,7 2530 0 2530

0,8 2528 0 2528

0,9 2529 0 2529

1,0 2528 0 2528

1,1 2525 1 2526

1,2 2528 0 2528

1,3 2529 0 2529

1,4 2527 2 2529

1,5 2528 1 2529

1,6 2523 3 2526











93


0,2 2531 0 2531

0,3 2531 0 2531

0,4 2531 0 2531

0,5 2528 0 2528

0,6 2530 0 2530

0,7 2530 0 2530

0,8 2528 0 2528

0,9 2529 0 2529

1,0 2528 0 2528

1,1 2526 0 2526

1,2 2528 0 2528

1,3 2529 0 2529

1,4 2528 1 2529

1,5 2529 0 2529

1,6 2525 1 2526


94


0,2 2531 0 2531

0,3 2531 0 2531

0,4 2531 0 2531

0,5 2528 0 2528

0,6 2530 0 2530

0,7 2530 0 2530

0,8 2528 0 2528

0,9 2529 0 2529

1,0 2528 0 2528

1,1 2526 0 2526

1,2 2528 0 2528

1,3 2529 0 2529

1,4 2528 1 2529

1,5 2529 0 2529

1,6 2525 1 2526


95

Capítulo 5

Conclusiones

El objetivo de esta tesis, ha sido el desarrollo e implementación de un prototipo de si-

mulador de planificador de tarea en sistemas de tiempo real con procesadores heterogéneos,

utilizando algoritmos de planificación por prioridades.

Se implementó dicho simulador, capaz de realizar planificaciones de N tareas de tiempo

real en M procesadores heterogéneos, utilizando 2 (dos) algoritmos de planificación por prio-

ridades (EDF y PF), junto con 2 (dos) posibles decisiones en caso de que la instancia de una

tarea alcanzara el tiempo máximo de espera (Aborto ó Terminación Tardía). Fueron realizadas

diferentes pruebas para garantizar el correcto funcionamiento de los algoritmos, realizando la

posibles combinaciones entre algoritmos y decisiones.

Se distinguieron y estudiaron los puntos críticos del planificador para los cuales se im-

plementaron casos testigos para testear el correcto comportamiento del simulador en dichas

circunstancias. Como resultado se observo que el simulador respondía de manera esperada ante

las pruebas que fueron detallas y explicadas en el capítulo 4.

97

Capítulo 6

Trabajos Futuros

Desarrollar e implementar los conceptos para considerar las demoras introducidas cuando

una tarea se despacha desde el procesador CPU (organizador) hacia otro procesador (pudiendo

ser otro CPU, un GPU o una FPGA), para que éste la ejecute y retorne el resultado al CPU (or-

ganizador) y así obtener la salida. Ante este intercambio se deben estudiar posibles sobrecargas

que conduzcan a reducir el rendimiento del sistema.

Analizar y estudiar los concepto para ampliar el uso de la FPGA, permitiendo que en una

misma FPGA, se puedan ejecutar de forma paralela más de una tarea en el mismo instante de

tiempo e introducir el uso de pipeline en las FPGA.

Que el simulador implementado, permita comparar diferentes métricas que permitan reali-

zar conclusiones sobre las planificaciones, permitiendo estudiar el rendimiento decreciente pro-

ducido al agregar mas procesadores para la ejecución de un conjunto de tareas finito. Además,

que permita realizar la comparación del consumo de energía utilizado en las planificaciones

usando distintas estrategias de planificación, para lo cuál sera necesario agregar un algoritmo

de planificación orientado a mejorar el consumo de energía en las planificaciones.

99

Bibliografía

Aguilar, J., Leiss, E., et al. (2004). Introducción a la computación paralela. Editorial Venezola-

na, Universidad de Los Andes, Mérida.

Audsley, N. C., Burns, A., Richardson, M. F., and Wellings, A. J. (1994). Stress: A simulator

for hard real-time systems. Software: Practice and Experience, 24(6):543–564.

Blanco de Frutos, H., Guirado Fernández, F., Monsó, L., and Lluís, J. (2012). Clusterización de

aplicaciones paralelas para su planificación en entornos de cómputo multi-cluster. Univer-

sitat de Lleida.

Bogdanski, M., Lewis, P. R., Becker, T., and Yao, X. (2011). Improving scheduling techniques

in heterogeneous systems with dynamic, on-line optimisations. In Complex, Intelligent

and Software Intensive Systems (CISIS), 2011 International Conference on, pages 496–

501. IEEE.

Brodtkorb, A. R., Dyken, C., Hagen, T. R., Hjelmervik, J. M., and Storaasli, O. O. (2010).

State-of-the-art in heterogeneous computing. Scientific Programming, 18(1):1–33.

Burns, A. and Wellings, A. J. (2010). Real-time systems and programming languages, volume

2097. Addison-Wesley.

Crespo, A. and Alonso, A. (2006). Una panorámica de los sistemas de tiempo real. Revista

Iberoamericana de Automática e Informática Industrial, 3(2):7–18.

101

De Giusti, L., Naiouf, M., Chichizola, F., Luque, E., and De Giusti, A. (2009). Dynamic sche-

duling in heterogeneous multiprocessor architectures. efficiency analysis. In Computer

Science & Technology Series–XV Argentine Congress of Computer Science Selected Pa-

pers. Editores: Guillerno Simari, Patricia Pesado, José Paganini. Págs, pages 85–95.

Diaz, A., Batista, R., and Castro, O. (2007). Realtss: a real-time scheduling simulator. In

Electrical and Electronics Engineering, 2007. ICEEE 2007. 4th International Conference

on, pages 165–168. IEEE.

Díaz, J., Reyes, S., Niño, A., and Muñoz-Caro, C. (2006). Un algoritmo autoplanificador cua-

drático para clusters heterogéneos de computadores. XVII Jornadas de Paralelismo, pages

379–382.

Flores, J. R. Z. (1995). Planificación estática de procesos en sistemas de tiempo real crítico.

PhD thesis, Universidad Politécnica de Madrid.

Golatowski, F., Hildebrandt, J., Blumenthal, J., and Timmermann, D. (2002). Framework for

validation, test and analysis of real-time scheduling algorithms and scheduler implementa-

tions. In Rapid System Prototyping, 2002. Proceedings. 13th IEEE International Workshop

on, pages 146–152. IEEE.

González Harbour, M., García, J. G., Gutiérrez, J. P., and Moyano, J. D. (2001). Mast: Mode-

ling and analysis suite for real time applications. In Real-Time Systems, 13th Euromicro

Conference on, 2001., pages 125–134. IEEE.

Healey, G., Slater, D., Lin, T., Drda, B., et al. (1993). A system for real-time fire detection.

In Computer Vision and Pattern Recognition, 1993. Proceedings CVPR’93., 1993 IEEE

Computer Society Conference on, pages 605–606. IEEE.

Hernández, L., Taibo, J., and Seoane, A. (1999). Una aplicación para la navegación en tiempo

real sobre grandes modelos topográficos. In IX Congreso Español de Informática Gráfica,

CEIG 1999.

102

Khatib, O. (1986). Real-time obstacle avoidance for manipulators and mobile robots. The

international journal of robotics research, 5(1):90–98.

Kramp, T., Adrian, M., and Koster, R. (2000). An open framework for real-time scheduling

simulation. Springer.

Krause, M., Englert, D., Bringmann, O., and Rosenstiel, W. (2008). Combination of instruc-

tion set simulation and abstract rtos model execution for fast and accurate target software

evaluation. In Proceedings of the 6th IEEE/ACM/IFIP international conference on Hard-

ware/Software codesign and system synthesis, pages 143–148. ACM.

Laplante, P. A. (1992). Real-Time Systems Design and Analysis: An Engineer’s Handbook.

IEEE Press, Piscataway, NJ, USA.

Liu, C. L. and Layland, J. W. (1973). Scheduling Algorithm for multiprogramming in Hard-

Real-Time Environment. Jornal of ACM.

Liu, J. W.-S., Liu, C. L., Deng, Z., Tia, T.-S., Sun, J., Storch, M., Hull, D., Redondo, J., Bettati,

R., and Silberman, A. (1996). Perts: A prototyping environment for real-tim e systems.

International Journal of Software Engineering and Knowledge Engineering, 6(02):161–

177.

Luna, F., Nesmachnow, S., and Alba, E. (2010). Búsqueda local paralela para planificación de

tareas en sistemas de computación heterogéneos. Universidad de Castilla, La Mancha.

Mednis, A., Strazdins, G., Zviedris, R., Kanonirs, G., and Selavo, L. (2011). Real time pothole

detection using android smartphones with accelerometers. In Distributed Computing in

Sensor Systems and Workshops (DCOSS), 2011 International Conference on, pages 1–6.

IEEE.

Moreno, L. (2004). Computación paralela y entornos heterogéneos. PhD thesis, Ph. D. disser-

tation, Universidad de La Laguna.

103

Olguín, G., Biscayart, L., and Urriza, J. M. (2012). Generación de tareas periódicas y aperió-

dicas para simulación de sistemas de tiempo real. Iberoamerican Journal of Industrial

Engineering, 3(6):53–69.

Orozco, J. D., Urriza, J. M., Cayssials, R., Fernández, E., Ferrari, M., Echaiz, J., Buckle, C.,

Barry, D., Páez, F. E., Olguín, G., et al. (2013). Sistemas de tiempo real con requerimien-

tos heterogéneos: integración hardware-software. In XV Workshop de Investigadores en

Ciencias de la Computación.

Páez, F. E., Urriza, J. M., and Orozco, J. (2014). Simulación de tareas aperiódicas y esporá-

dicas de tiempo real mediante un modelo de eventos discretos. Iberoamerican Journal of

Industrial Engineering, 5(10):251–264.

Pérez, H. P. (2003). Sistemas operativos de tiempo real (rtos). Revista española de electrónica,

Ediciones Técnicas REDE, pages 42–43.

Ramón, H. D. and Romero, F. (2002). Sistemas en tiempo real. In IV Workshop de Investiga-

dores en Ciencias de la Computación.

Rivas, M. A. (2002). Planificación de tareas en sistemas operativos de tiempo real estricto para

aplicaciones empotradas. Doctor, Facultad de Ciencias, Departamento de Electrónica y

Computadores, Universidad de Cantabria, Santander, España.

Singhoff, F., Legrand, J., Nana, L., and Marcé, L. (2004). Cheddar: a flexible real time schedu-

ling framework. In ACM SIGAda Ada Letters, volume 24, number 4, pages 1–8. ACM.

Vroey, S. D., Goossens, J., and Hernalsteen, C. (1996). A generic simulator of real-time schedu-

ling algorithms. In Simulation Symposium, 1996., Proceedings of the 29th Annual, pages

242–249. IEEE.

104

prototipo de simulador de planificador de tareas …

Documents