master degree: industrial systems engineering...que los requisitos de temporización, para no...

PAC- Performance-centered Adaptive Curriculum for Employment Needs Programa ERASMUS: Acción Multilateral - 517742-LLP-1-2011-1-BG-ERASMUS-ECUE

MASTER DEGREE:

Industrial Systems Engineering

ASIGNATURA ISE4:

Comunicaciones industriales y en Tiempo Real

MÓDULO 2: Sistemas en Tiempo Real

TAREA 2-2: SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO

RTOS

Sistemas en Tiempo Real (RTS)

SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS 2

Contenido Comunicaciones industriales y en Tiempo Real .............................................................. 1

TAREA 2-2: SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS. .............................................................................................................. 3

1. INTRODUCCIÓN Y OBJETIVOS ................................................................................. 3

2. CONTENIDO ..................................................................................................................... 3

2.1 APARTADO 1: Características de los sistemas operativos en tiempo real. ...................................................................................................................................... 3

2.2 APARTADO 2: RTSJ – Real Time Specification for Java ......................... 12

2.3 APARTADO 3: Tipos de memoria y su uso en RTS de Java ................. 14

2.4 APARTADO 4: Funcionamiento del recolector de basura (Garbage Collector – G.C.) ........................................................................................................... 17

2.5 APARTADO 5: Tarea propuesta. ..................................................................... 21

3. CONCLUSIONES ........................................................................................................... 22

4. BIBLIOGRAFÍA Y/O REFERENCIAS ....................................................................... 23

5. ENLACES DE INTERÉS ............................................................................................... 24

Índice de figuras Figura 1: Ejemplo ........................................................................................................................... 9 Figura 2: Distribución del espacio alojado frente a la edad ........................................................ 18 Figura 3: Generaciones en el montículo de Java ......................................................................... 20 Índice de tablas



TAREA 2-2: SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS.

1. INTRODUCCIÓN Y OBJETIVOS Se realizará una breve introducción a la tarea a realizar en la que se describa la tarea y el objetivo perseguido: En la Tarea 2-2: Sistemas operativos para Tiempo Real (RTOS). Java (RTSJ) como RTOS, se pretende hacer una breve descripción y comparación del sistema operativo en tiempo real utilizando material de la teoría y de Internet. También se pretende estudiar dónde está el lugar de RTS Java entre otros sistemas operativos en tiempo real.

Entre los objetivos de dicha tarea, se pretende que el alumno tenga claros los conceptos de "prioridades" y "cadenas" que se utiliza en el Tiempo Real Java System, así como investigar sobre los tipos de memoria y su uso en RTS de Java y el funcionamiento del recolector de basura (Garbage Collector – G.C.)

Se propone además, resolver la prueba dada en tarea2_2_Test_ES.doc, en respuesta al trabajo, el alumno debe especificar las respuestas correctas de la siguiente forma: 1A, 2C ... etcétera

2. CONTENIDO

2.1 APARTADO 1: Características de los sistemas operativos en tiempo real. En primer lugar se realizará una breve descripción y comparación del sistema operativo en tiempo real. Un sistema de tiempo real (STR o real-time system o RTS) es aquel cuyo correcto funcionamiento depende de que las salidas “lleguen a tiempo”, es decir, que debe estar acotado el tiempo entre cada evento y la respuesta que provoca, no necesariamente tiene que ser breve, pero sí acotado. Se distinguen dos tipos:

- STR duro (hard RTS): Es duro cuando el incumplimiento de un deadline implica un funcionamiento incorrecto. Ejemplos: El sistema ABS (anti-lock breaking system) de un auto, un marcapasos.



- STR suave (soft RTS): Es suave cuando el incumplimiento de un deadline no implica funcionamiento incorrecto pero sí una degradación en la calidad de servicio. Ejemplos: Procesamiento de video, porque es aceptable que se pierda algún que otro cuadro, un reproductor de DVD.

Requerimientos de un STR: Un STR está definido por una lista de: Los eventos externos que puede atender La respuesta lógica (o sea, salida) que debe producir cada evento Los requerimientos de temporización de esas respuestas (sus deadlines relativos). Para simplificar, los STR suaves frecuentemente se diseñan como si fueran STR duros, es decir, como si sus deadlines fueran estrictos Requerimientos de temporización: A veces se recurre a métodos formales para verificar el cumplimiento de los requerimientos de temporización, pero es más frecuente testearlos mediante simulaciones y pruebas en prototipos. Los problemas que se presentan: Ante cambios menores, hay que volver a testear todo, el testeo nunca da garantías al 100%. Es muy valioso usar técnicas de programación que nos den cierta seguridad sobre el cumplimiento que los requisitos de temporización, para no depender mucho de la verificación. Para cumplir esos requerimientos, a veces hay que evitar usar técnicas que implican tiempos largos y/o poco predecibles. Algunos ejemplos son los siguientes: programación orientada a objetos, Garbage collecting (como el de Java), malloc() y free() comunes de C. Diseño de un STR: dado que un STR es un sistema reactivo con requisitos (estrictos o no) en cuanto a sus tiempos de respuesta, dichos requisitos se consideran desde la etapa de elaboración de requerimientos y durante todo el proceso de diseño. A diferencia del diseño de un software transaccional común, en los cuales lo típico, como mucho, es chequear la velocidad una vez programadas sus unidades, para decidir si optimizarlas o no. Es necesario tener en cuenta que “reactivo” significa que responde a eventos externos, que no necesariamente tienen orden o periodicidad Un STR puede diseñarse directamente en Assembly sin librerías ni nada. Sin embargo, en sistemas medianamente complejos, suele ser difícil asegurar los requisitos de temporización, por ello debemos valorar las técnicas de programación que dan cierta seguridad sobre el cumplimiento que esos requisitos. A veces es conveniente utilizar un sistema operativo de tiempo real (real-time operating system o RTOS).



Un sistema operativo de tiempo real (RTOS) es un software de base que simplifica el diseño de software con requerimientos de tiempo real. Permite que el programador estructure la aplicación como un conjunto de tareas concurrentes, (concurrentes quiere decir que se ejecutan al mismo tiempo). Así, el procesamiento de cada evento se asigna a una tarea, pudiéndose obtener una demora razonablemente corta entre el evento y la ejecución de la tarea, sin que haya que escribir un código muy intrincado. Normalmente, las tareas no son realmente concurrentes, sino que el procesador se reparte entre ellas, creando esa ilusión. El RTOS gestiona la ejecución de esas tareas y provee servicios que la aplicación utiliza para acceder, con tiempos razonables y predecibles, al hardware. Por ejemplo, para manejar memoria y entrada/salida. Comparación con OS comunes: Existen similitudes usuales con sistemas operativos de propósitos generales, como pueden ser las siguientes:

- Multitasking. O sea, ejecución de tareas (tasks) concurrentes - Provisión de servicios para las aplicaciones - Ligera abstracción del hardware - Un kernel: es un núcleo del sistema operativo, que está siempre en

memoria gestionando la ejecución de las tareas y sirviendo de puente con el hardware. Sin embargo, algunos RTOS son solo librerías, o sea, kernel-less.

Las diferencias principales son las siguientes: En los RTOS, la gestión del multitasking está especialmente diseñada para atender requisitos de tiempo real. No suelen incluir interfaces al usuario gráficas, solo a veces incluyen gestión de archivos en disco, etc. Son programas mucho más livianos. Los hay especiales para sistemas que requieren una confiabilidad excepcional, es decir, sistemas de misión crítica o seguridad crítica Podemos citar algunos RTOS conocidos, como son los siguientes: VxWorks

- De Wind River, que es subsidiaria de Intel desde julio de 2009 - Con soporte para multiprocesadores, IPv6 y un sistema de archivos - Con protección de memoria, es decir, que las tareas no pueden alterar

la memoria de trabajo de otras tareas - Funciona en las plataformas de embebidos más populares - Se usa con un IDE para Windows/Linux, que normalmente incluye

depurador, simulador y herramientas de análisis



QNX

- De QNX, subsidiaria de Research in Motion (los del Blackberry) desde mayo de 2010

- Símil Unix, ofrece funcionalidad parecida al VxWorks - En 2007 fue abierto el código de su núcleo

RTLinux - Basado en Linux

FreeRTOS Existen básicamente dos maneras de organizar un OS: de núcleo (kernel) monolítico, que son todas las funciones “residentes” del OS están en su núcleo, o la segunda forma de organizar un OS podría ser con microkernel: que quiere decir que algunas funciones del OS se implementan como tareas similares a las de la aplicación. Como ejemplo podemos citar VxWorks, el cual utiliza kernel monolítico, mientras que QNX, RTLinux y FreeRTOS usan microkernel (µkernel). Los Sistemas operativos de Tiempo Real, se caracterizan por presentar requisitos especiales en cinco áreas generales:

- Determinismo - Sensibilidad - Control del usuario - Fiabilidad - Tolerancia a los fallos

Un sistema operativo es determinista si realiza las operaciones en instantes fijos y predeterminados o en intervalos de tiempos predeterminados. Cuando compiten varios procesos por los recursos y por el tiempo del procesador, depende, en primer lugar, de la velocidad con la que pueda responder a las interrupciones y en segundo lugar, de si el sistema posee suficiente capacidad para gestionar todas las peticiones en el tiempo requerido. Un sistema operativo, para operar de forma determinista, es el retardo máximo que se produce de la llegada de la interrupción de un dispositivo de alta prioridad hasta que comienza el servicio. La sensibilidad. El determinismo hace referencia a cuánto tiempo necesita un sistema operativo en reconocer una interrupción. Este concepto de sensibilidad se refiere a cuánto tiempo consume un sistema operativo en dar servicio a la interrupción después de reconocerla. Podemos citar como características de la sensibilidad las siguientes:



1.- La cantidad de tiempo necesario para iniciar la gestión de la interrupción y comenzar la ejecución de su rutina de tratamiento (ISR, interrupt service routine). 2.- La cantidad de tiempo necesario para ejecutar la ISR. Normalmente, depende de la plataforma del hardware. 3.- El efecto del tratamiento de interrupciones. El servicio se retrasara si una ISR puede ser interrumpida por la llegada de otra interrupción. El determinismo y la sensibilidad constituyen el tiempo de respuesta a sucesos externos. Los requisitos en tiempo de respuesta son críticos ya que cada sistema debe cumplir los requisitos de tiempo impuesto por los individuos, dispositivos y flujos de datos externos al sistema. El control del usuario es mucho mayor en un sistema operativo en tiempo real que en un sistema operativo ordinario. En un sistema operativo típico que no sea en tiempo real, el usuario no tiene control sobre la función de planificación del sistema operativo. En un sistema en tiempo real resulta esencial permitir al usuario que pueda tener un control preciso sobre la prioridad de las tareas. El usuario debe poder distinguir entre tareas rígidas y flexibles y de esta forma, especificar prioridades relativas dentro de cada clase. Un sistema en tiempo real también permitirá al usuario especificar características, es decir, qué procesos deben estar siempre residentes en la memoria principal. La fiabilidad es normalmente mucho más importante en sistemas en tiempo real que en los que no lo son. Un fallo transitorio en un sistema que no sea en tiempo real puede resolverse simplemente volviendo a reiniciar el sistema. Un fallo de un procesador en un multiprocesador que no sea en tiempo real produce una reducción del nivel de servicio hasta que se repara o sustituye el procesador averiado. Como ya se comentó en la tarea 2_1, las pérdidas o degradaciones del rendimiento pueden tener consecuencias catastróficas, que pueden ir desde perdida financieras hasta daños en equipo e incluso pérdida de vidas humanas. La tolerancia a los fallos es una característica que hace referencia a la capacidad de un sistema de conservar la máxima capacidad y los máximos datos posibles en caso de fallos por Ej., un sistema UNIX clásico típico, cuando detecta datos corruptos en el núcleo, genera un mensaje de error en la consola del sistema, vuelca el contenido de la memoria en el disco para un análisis posterior y finaliza la ejecución del sistema. Un sistema en tiempo real intentará corregir el problema o minimizar su efecto mientras continúa la ejecución.



Para cumplir los requisitos anteriores, los sistemas operativos actuales en tiempo real incluyen normalmente las siguientes características:

- Cambios rápidos de procesos o hilos. - Pequeño tamaño (con una mínima funcionalidad asociada). - Capacidad de responder rápidamente a interrupciones externas. - Multitarea con herramientas de comunicación entre procesos, como

semáforos, señales y sucesos. - Uso de archivos secuénciales especiales que puedan acumular datos a

alta velocidad. - Planificación preferente basadas en prioridades. - Reducción de intervalos en los que están inhabilitadas las

interrupciones. - Primitivas para demorar tareas durante un tiempo fijo y para detenerlas

y reanudarlas. - Alarmas especiales y temporizadores.

El motor de un sistema en tiempo real es el planificador de tareas a corto plazo. Lo que resulta importante es que todas las tareas rígidas de tiempo real acaben (o comiencen) en su plazo y que también acaben (o comiencen) en su plazo tantas tareas flexibles de tiempo real como sea posible. La mayoría de los sistemas operativos actuales en tiempo real son incapaces de trabajar directamente con plazos. En su lugar, se han diseñado de forma que sean tan sensibles como sea posible a las tareas de tiempo real, de forma que, cuando se aproxima un plazo se pueda planificar rápidamente la tarea. Las aplicaciones de tiempo real normalmente necesitan tiempos de respuesta deterministas en un rango de varios milisegundos, las aplicaciones al límite, como los simuladores de aviones militares, por ej. presentan a menudo restricciones en un rango de diez a cien microsegundos. Si el tener un fallo en el tiempo de latencia de un proceso del sistema lleva como consecuencia un error en el sistema, entonces esos procesos se consideran de tiempo real duro. Si el tener un fallo en un proceso del sistema no conlleva un fallo en el sistema siempre y cuando este fallo esté dentro de ciertos límites establecidos (es posible fallar en la latencia una de cada 1000 veces o una de cada 100, o fallar siempre y cuando el error no exceda el 3% de la latencia) entonces esos procesos se llaman procesos de tiempo real suave. Los componentes de un RTOS son los siguientes:

- Programador (scheduler): el cual establece el orden de ejecución de los procesos.



- Ejecutor (dispatcher): el cual gestiona el inicio y la finalización de cada tramo de procesamiento, cambiando el contexto (stack, memoria, registros, etc.) para pasar de una tarea a otra.

- Administrador de memoria: En arquitecturas con µkernel, éste suele contener al scheduler, al dispatcher y al administrador de memoria.

- Servicios: se refiere a los drivers para acceder al hardware, el administrador de interrupciones de hardware o software, etc.

- Primitivas para la sincronización y comunicación entre procesos. Podemos citar otros componentes (empleados para misión crítica):

- Gestor de configuraciones (configuration manager): Gestiona la reconfiguración del sistema (reemplazo de componentes de hardware o actualización de software) sin interrumpir el funcionamiento del sistema.

- Gestor de fallas (fault manager): Detecta fallas de hardware y software, y toma acciones para asegurar la disponibilidad del sistema.

- Ejemplo: RadioBase de Telefonía Celular, el cual tiene alta disponibilidad (tolerancia a fallas mediante redundancia), actualizaciones de software y hardware sin detención, reporte de estadísticas de funcionamiento y performance, reconfiguración según necesidades, por tráfico, variación del espectro, etc.

En lo referente al Multitasking, el procesador (usualmente) se reparte entre distintas tareas, creando la ilusión del procesamiento concurrente:

Figura 1: Ejemplo

En el ejemplo de la figura 1, el procesador primero está ejecutando la tarea A. Ésta le hace un pedido a la B, así que se transfiere el control del procesador a ésta última, hasta que requiere la respuesta de un periférico. Mientras espera, se le da el control a la tarea C, hasta que ésta termina lo que hacía y llama a una función especial del scheduler, mediante la cual queda en espera mientras no tenga nada que hacer. El procesador vuelve con B, dado que la respuesta que esperaba ya



llegó. Por último, B termina de realizar el pedido de A, así que se le devuelve el control a ésta. Como vemos, cada tarea está en uno de tres estados:

- Lista para ser atendida por el procesador - Siendo ejecutada por el procesador - Bloqueada (también se le denomina suspendida)

Programación (Scheduling): ¿Quién decidió que A esté seguido de B, si podía haber arrancado C ahí? ¿O que se haya ejecutado C en el intervalo, en lugar de alguna otra tarea (D, E, etc.) que estuviera lista? Lo decidió el scheduler del RTOS, en base al algoritmo de programación (o scheduling algorithm) definido al diseñar el sistema. Esas decisiones (es decir, la programación de tareas, o scheduling) tienen un rol crucial en el cumplimiento de los requisitos de temporización. Ej., deben tener prioridad las tareas con deadline inminente El dispatcher mientras tanto se ocupó, en aquellos momentos donde se pasó a procesar otra tarea, de lo siguiente:

- Tomar una de una lista (ordenada) de tareas listas que fue preparada por el scheduler

- Cambiar el contexto (es decir, hacer el context switch) - Transferir el control del procesador a la instrucción que corresponde,

de la nueva tarea Preemptive Scheduling: En el ejemplo anterior, el cambio de una tarea a otra se da sólo cuando el proceso en ejecución solicita un servicio del sistema. Puede ser porque realmente requiere el servicio (ej., un acceso a un periférico) o porque está programado que ahí debe liberar al procesador (como lo había hecho C). Pero la mayoría de los sistemas operativos pueden también interrumpir la tarea que se está ejecutando, cuando pasa demasiado tiempo sin “devolver” el procesador, a esto se le dice programación preventiva (o preemptive scheduling o preemptive multitasking). Para realizarlo, se necesita algún timer o reloj de tiempo real (RTC) y es preventiva porque no depende de que las tareas devuelvan el control a tiempo A la programación de tareas que no hace estas interrupciones, se les dice programación cooperativa (o cooperative scheduling) Funcionamiento del scheduler: Típicamente, el scheduler se ejecuta a intervalos regulares, determinados por un timer o reloj de tiempo real (RTC), cuando lo hace, vuelve a elaborar la lista de tareas listas (la que lee el dispatcher), dándoles un orden que, idealmente, depende del tiempo remanente hasta el deadline de cada una.



Existen varios tipos de algoritmos para la elaboración de este orden, esos son los algoritmos de scheduling que mencionamos antes Por un lado, tenemos el Scheduling preventivo, basado en prioridades, es decir, el programador asigna una prioridad a cada proceso, de los cuales se ejecuta siempre el proceso de mayor prioridad, entre los que están listos. Si aparece uno de mayor prioridad, se interrumpe la ejecución y se le da el control Las prioridades pueden ser fijas o dinámicas. Son dinámicas si pueden modificarse en tiempo de ejecución, depende de que las tareas de alta prioridad devuelvan el control (similar al scheduling cooperativo). El problema que existe es que por más que lo hagan, puede pasar mucho tiempo hasta que se ejecutan los de baja prioridad, ya que siempre hay una de mayor prioridad que está lista. A esa situación se le llama starvation. Por otro lado, nos encontramos con el Round-robin (en ronda), en el cual los procesos se ejecutan siempre en la misma secuencia, se emplea cuando el multitasking es preemptive, asignándoles, a las tareas, fragmentos de tiempo (o time slices) de igual duración, puede resultar útil combinarlo con el algoritmo anterior. Entre los mejores algoritmos, se encuentra el Rate-monotonic scheduling, que consiste en un esquema basado en prioridades (fijas), en donde la prioridad de una tarea es inversamente proporcional a su deadline relativo En cuanto a la sincronización y comunicación entre procesos, podríamos imaginarnos las siguientes tareas:

- Una tarea produce ciertos datos que son ingresados por un usuario, o los resultados de un cálculo, o lo que sea)

- Otra tarea consume esos datos, es decir, los imprime, los usa para otros cálculos. Mientras no reciba datos, esta tarea queda suspendida.

Nos encontramos ante un problema típico, se llama productor – consumidor. Con el objetivo de resolverlo necesitamos medios para que la primera le comunique cada dato a la segunda (a esto se le llama comunicación entre procesos) y además, que la primera señalice que le acaba de mandar un dato a la otra, para que esta pase del estado “bloqueada” al estado “lista”, y pueda leerlo (a esto se le llama sincronización de procesos). Primitivas para la sincronización y comunicación:



Los RTOS suelen ofrecer elementos para la comunicación, como por ejemplo: memoria compartida, colas de mensajes, mailboxes. Y también para la sincronización, como por ejemplo: semáforos, mutex En cuanto a la memoria compartida, se pueden definir partes de memoria accesibles por los dos procesos que necesitan comunicarse. Los datos pueden ser comunicados escribiéndolos allí, pero hay que tener cuidado, que un proceso no interprete un dato a medio escribir, como si estuviera escrito del todo. Es decir que se necesita algo como un handshaking. Por ejemplo, una señal de sincronización. Las Colas (queues) de mensajes son colecciones ordenadas de (estructuras de) datos que se puede ingresar un elemento al final, o sacar uno del principio. Se trata de una estructura first-in, first-out (FIFO). Es una estructura de nivel más alto que la memoria compartida, que incluye sincronización.

2.2 APARTADO 2: RTSJ – Real Time Specification for Java El lenguaje Java utiliza una herramienta muy útil para el programador: el recolector de basura, que hace que no nos tengamos que preocupar de tareas como liberar memoria. El problema es que en un sistema de tiempo real no se puede detener el control del programa para un algoritmo tan costoso en tiempo como es el del colector de basura. Una alternativa es la propuesta por la especificación de tiempo real para Java; The Real-Time Specification for Java (RTSJ), que propone un modelo basado en regiones, agrupando objetos con tiempo de vida similar. Una de las aportaciones del entorno Java es la recolección automática de espacios no utilizados (garbage collection o recolección de basura). Dado que existe una sobrecarga de tiempo y de memoria que las técnicas de recolección requieren, esto hace incompatible su empleo en sistemas de tiempo real. Por otra parte, la recolección implícita de los espacios de memoria no usados permite el desarrollo de programas robustos, ya que el programador se libera de dicha tarea, concentrando sus esfuerzos en el desarrollo de la aplicación. Un método intermedio y alternativo consiste en agrupar los objetos con un tiempo de vida similar en regiones de memoria que son recolectadas de forma implícita. Gestión de la memoria: La gestión automática de la memoria es una característica de Java particularmente importante, por lo que RTSJ permite, en la medida de lo posible, que la gestión de memoria sea implementada por el sistema y no introducirla en las tareas de programación. Para acomodar los diferentes conjuntos de recolección de basura se define un sistema de ubicación (allocation) de memoria que debería:



- Ser independiente de cualquier algoritmo de recolección de basura en particular.

- Permitir al programa caracterizar de forma precisa el efecto de un algoritmo de recolección de basura sobre el tiempo de ejecución, las prioridades, y el envío de los hilos Java en tiempo real.

- Permitir la ubicación de objetos sin interferencia de ningún algoritmo de recolección de basura

Sincronización y compartición de recursos: La lógica normalmente requiere un acceso en serie a los recursos. Los sistemas en tiempo real añaden cierta complejidad: controlar la inversión de prioridades. La especificación menos intrusiva para permitir una sincronización segura en tiempo real es requerir que las implementaciones de la directiva synchronized de Java incluyan uno o más algoritmos que prevengan la inversión de prioridad entre hilos Java en tiempo real que comparten un recurso. También se tuvo en cuenta que algunas veces el uso de la directiva synchronized que implemente el algoritmo de inversión de prioridades requerido no es suficiente para prevenir la inversión de prioridades y permitir que los hilos tengan una elegibilidad de ejecución mayor que el colector de basura. Se proveen un conjunto de clases sin cola de espera para usarlas en dichas situaciones, de las que se ha hablado anteriormente (queue). Manejo de eventos asíncrono: Los sistemas en tiempo real normalmente interactúan de forma muy cercana con el mundo real. Respecto a la ejecución de lógica, el mundo real es asíncrono. RTSJ generaliza el mecanismo de Java para manejar eventos asíncronos. Las clases requeridas representan cosas que pueden suceder y lógica que se ejecuta cuando estas cosas ocurren. Una característica notable es que la ejecución de dicha lógica es planificada y enviada a ejecutarse por un planificador implementado. Transferencia del control asíncrona: Algunas veces el mundo real cambia de forma tan drástica (y asíncrona) que el punto actual de ejecución debe ser inmediatamente cambiado a otro punto. RTSJ incluye un mecanismo que extiende el manejo de excepciones de Java para permitir aplicaciones que cambien el control de otro hilo Java. Es importante resaltar que RTSJ restringe esta transferencia de control asíncrona a situaciones específicamente escritas con la asunción de que la localización de su control puede cambiar de forma asíncrona. Finalización asíncrona de hilos: De nuevo, debido a los drásticos y asíncronos cambios del mundo real, la lógica de la aplicación necesita una forma de transferir segura su control a su exterior y terminar de una manera normal. El mecanismo RTSJ para manejo de eventos asíncronos y transferencia del control es seguro.



Acceso a memoria física: Aunque no es un aspecto ligado únicamente a los sistemas en tiempo real, el acceso a memoria física es deseable para la mayoría de las aplicaciones que pueden hacer un uso productivo de una implementación de RTJS. Se define una clase que permite a los programadores un acceso a memoria física a nivel de byte así como una clase que permite la construcción de objetos en memoria física. Java es un sistema multi-thread (multi-hilo), ya que permite muchas actividades simultáneas en un programa. Los threads (hilos), son pequeños procesos de un gran proceso. Al estar los threads incluidos en el lenguaje, son más fáciles de usar y más robustos que sus implementaciones en otros lenguajes. Esto tiene sus ventajas, como un mejor rendimiento interactivo y comportamiento en tiempo real. Aunque el comportamiento en tiempo real está limitado a las capacidades del sistema operativo sobre el que se ejecuta, aún supera a los entornos de flujo único de programa (single-threaded) tanto en desarrollo como en rendimiento. Java es un lenguaje de programación que incorpora threads en el núcleo del mismo lenguaje. Los threads son implementados a nivel de sistema, requiriendo una interfaz de programación específica separada del núcleo del lenguaje de programación. Java se presenta como ambos, como lenguaje y como sistema de tiempo de ejecución (runtime), siendo posible integrar threads dentro de ambos. El resultado final es que se pueden usar threads de Java como estándar en cualquier plataforma.

2.3 APARTADO 3: Tipos de memoria y su uso en RTS de Java Los threads en Java, comparten el mismo espacio de memoria. Además comparten gran parte del entorno de ejecución, de esta forma, la creación de nuevos threads es mucho más rápida que la creación de nuevos procesos. La ventaja que proporcionan los threads es la capacidad de tener más de un camino de ejecución en un mismo programa. Así, con un único proceso, ejecutándose una JVM (Java Virtual Machine), puede haber más de un thread, cada uno con su propio camino de ejecución. Java tiene un planificador (Scheduler), ya mencionado anteriormente, que decide qué threads deben ejecutarse y cuáles deben encontrarse preparados para su ejecución. Hay dos características de los threads que el planificador tiene en cuenta en este proceso de decisión. Lo primero que tiene en cuenta ya que es lo más importante, es la prioridad del thread. El planificador puede seguir dos patrones, preventivo y no preventivo: • Los planificadores preventivos proporcionan un segmento de tiempo a cada thread que se esté ejecutando en el sistema. El planificador decide cuál será



el siguiente thread a ejecutarse y le da vida durante un periodo de tiempo fijo. Cuando finaliza ese periodo de tiempo se suspende y se lanza el siguiente thread en la lista de procesos. • Los planificadores no preventivos, en cambio, deciden cuál es el thread que debe correr y lo ejecutan hasta que concluye. El thread tiene control total sobre el sistema mientras esté en ejecución. Un thread puede forzar al planificador para que comience la ejecución de otro thread que esté esperando. Los threads presentan algunos problemas para tiempo real, por ejemplo que no se pueden especificar características como el deadline, el jitter... por eso para tiempo real Java utiliza unos hilos específicos, los threads de tiempo real. Los programas informáticos hacen uso de una cierta cantidad de memoria de trabajo puesta a su disposición por el sistema operativo. Esta memoria será gestionada por el programa con el objeto de reservar espacios de memoria para su uso, liberar espacios de memoria previamente reservados, llevar un control sobre los espacios libres. El propio programador es responsable de utilizar adecuadamente la biblioteca. Esto permite realizar un uso eficiente de la memoria, por tanto, los espacios de memoria quedan libres cuando ya no son necesarios. No obstante, este mecanismo explícito de gestión de memoria es propenso a errores. Por tanto, se necesita una gestión implícita de memoria, donde el programador no es consciente de la reserva y liberación de memoria. Java utiliza un algoritmo colector de basura. En Java, el programador no tiene que invocar a una subrutina para liberar memoria. La reserva de memoria también es más o menos automática sin la intervención del programador, esto quiere decir que se reserva memoria cada vez que el programador crea un objeto, pero éste no tiene que conocer cuánta memoria se reserva. El recolector de basura utiliza como algoritmo típico, el colector de seguimiento, que sigue los objetos que son alcanzables por un conjunto de objetos raíz, para determinar qué objetos deberían permanecer en memoria y cuáles no. Los objetos alcanzables sobreviven al colector de basura porque podrían ser utilizados más adelante en la ejecución del programa. El uso del recolector de basura posee la ventaja de que el programador no puede cometer errores y queda liberado de la tediosa tarea de gestionar la memoria. Pero tiene otras desventajas como que la memoria permanezca retenida durante más tiempo del estrictamente necesario y que el colector de basura tarde cierto tiempo en ejecutar su tarea, por lo que el programa siempre será poco eficiente.



RTSJ introduce el concepto de área de memoria. Un área de memoria es una porción de memoria que se debe usar para la ubicación de objetos. Algunas áreas de memoria existen fuera del montón y restringen lo que el sistema y el colector de basura pueden y deben hacer con los objetos ahí ubicados. Algunos objetos en estas áreas de memoria nunca son tratados por el colector, sin embargo el colector debe ser capaz de escanear estas áreas de memoria en busca de referencias a objetos que estén en el montón, para conservar la integridad del mismo. Dado que en un sistema de tiempo real crítico, no puede pararse ni un momento el control de los hechos del sistema y menos para un algoritmo tan costoso cómo es el del colector de basura de Java, como alternativa la especificación de Java para tiempo real (RTSJ) introduce las regiones de memoria, presentando los siguientes tipos de regiones:

- Heap Memory: es el espacio de memoria que se colecta por el algoritmo de colector de basura. Solo puede haber una región de este tipo. RTSJ no cambia el tiempo de vida de los objetos del montón. El tiempo de vida es todavía determinado por su visibilidad, es decir, los objetos permanecen mientras sean referenciados, sin embargo, cuando dejan de ser referenciados son eliminados automáticamente por el recolector de basura (el momento concreto, dependerá de la implementación). Esta zona de memoria es compartida por todos los threads de tiempo real del sistema.

- Scoped Memory: los objetos de esta región tienen un tiempo de vida

limitado y cuando pasa este tiempo se destruye junto con los objetos que contiene. Es decir, la scoped memory proporciona un mecanismo para la gestión de objetos que tienen un tiempo de vida definido por su alcance. Puede haber varias instancias de regiones Scoped. No hay recolección de basura. Los objetos de esta zona se eliminan cuando se sale de método enter o termina el último thread que utiliza esta zona, es decir, se eliminan aunque existan referencias a objetos en ella. Las regiones scoped pueden ser:

o a. Scoped constante: que requiere que el tiempo de asignación sea directamente proporcional al tamaño del objeto que está siendo asignado.

o b. Scoped variable: donde la asignación puede producirse en un tiempo variable.

- Inmortal Memory: los objetos almacenados existen hasta que la aplicación finaliza (por ello no hay recolección de basura, la ejecución del GC nunca puede retrasar la creación de objetos en esta zona). Sólo puede haber una región de este tipo por cada JVM. Representa un área de memoria que contiene objetos que se referencian desde objetos



planificables, sin excepciones ni retrasos causado por el colector de basura. Esta zona de memoria es compartida por todos los threads de tiempo real del sistema.

- Inmortal Physical Memory: permite la creación de objetos en regiones

específicas de memoria que tienen alguna característica importante (por ejemplo una región que tiene un acceso más rápido). Los objetos de esta región hacen referencia a zonas de memoria física concretas. Puede haber varias instancias de regiones de este tipo. Los objetos creados aquí tienen un tiempo de vida igual al de la aplicación (no hay recolección de basura). Permite modificar parámetros de acceso a estas regiones, por ejemplo, los parámetros de seguridad.

2.4 APARTADO 4: Funcionamiento del recolector de basura (Garbage Collector – G.C.) El recolector de basura es el principal cuello de botella en muchas aplicaciones, por lo que es interesante entender los detalles de su implementación. El recolector de basura presupone que las aplicaciones utilizan los objetos de una manera determinada, y esto se refleja en parámetros que pueden ser ajustados para mejorar su funcionamiento sin sacrificar la potencia de la abstracción. Un objeto es basura cuando no puede ser alcanzado (no tiene referencias fuertes) desde ningún punto del programa que se está ejecutando. El método más directo de recolección de basura es iterar sobre cada objeto alcanzable, y se asume que todos aquellos por los que no se pase son basura. Este enfoque tarda un tiempo proporcional al número de objetos vivos, lo que es prohibitivo para grandes aplicaciones que mantienen gran cantidad de objetos vivos. Versiones recientes de la JVM incorporan una serie de diferentes algoritmos de recolección de basura que se combinan utilizando la recolección generacional. Mientras la recolección ordinaria examina cada objeto vivo en el montículo, la recolección generacional aprovecha ciertas propiedades de las aplicaciones observadas empíricamente para evitar trabajo extra. La más importante de estas propiedades es la mortalidad infantil. El área azul del diagrama siguiente es una distribución típica del tiempo de vida de los objetos. El pico de la izquierda representa objetos que han dejado de ser utilizados rápidamente después de haber sido creados. Los objetos iterados, por ejemplo, a menudo viven, únicamente, la duración de un bucle.



Figura 2: Distribución del espacio alojado frente a la edad

Algunos objetos viven más, y por eso la distribución se estrecha hacia la derecha. De hecho, algunos objetos creados al inicio viven hasta que el proceso termina. Entre estos dos extremos hay objetos que viven durante algún cálculo intermedio, véase el lóbulo a la derecha del pico de mortalidad infantil. Algunas aplicaciones tienen distribuciones diferentes, pero la mayoría siguen este patrón. La recolección eficiente se lleva a cabo fijándose en el hecho de que la mayoría de los objetos mueren jóvenes. Para hacer esto, la memoria se organiza en generaciones: espacios de memoria que contienen objetos de diferentes edades. La recolección de basura se produce en cada generación cuando ésta se llena. Los objetos se sitúan en el edén y, debido a la mortalidad infantil, la mayoría muere ahí. Cuando el edén se llena se produce una recolección menor en la que algunos objetos supervivientes se mueven a una generación más vieja. Cuando las generaciones viejas se llenan se produce una recolección mayor que, generalmente, es mucho más lenta debido a que involucra a todos los objetos vivos. La figura 2 muestra un sistema bien ajustado en el que la mayoría de los objetos no sobrevive a la primera recolección de basura. Cuanto más tiempo sobreviva un objeto, más recolecciones pasarán sobre él, y el recolector de basura se volverá más lento. La recolección de basura será más eficiente haciendo que los objetos no sobrevivan a la primera recolección. Las aplicaciones pueden trastornar esta situación ideal con distribuciones de tiempo de vida inusuales o con generaciones de tamaño pequeño que causan recolecciones con demasiada frecuencia.



Los parámetros por defecto del recolector de basura funcionan bien para pequeñas aplicaciones. Sin embargo, se pueden modificar estos parámetros para evitar que el recolector de basura se convierta en el cuello de botella de la aplicación. Existen varios tipos de recolección, teniendo en cuenta que cada generación tiene asociada un tipo de recolección de basura que puede ser configurada para realizar diferentes políticas algorítmicas en tiempo, espacio y pausa. En JVM 1.3 hay tres tipos diferentes de recolectores: - Copiar (copying, también llamado scavenge): Este recolector mueve de forma muy eficiente objetos vivos entre dos o más generaciones. Todo lo que queda en las generaciones fuente se deja como basura, de forma que los objetos muertos son reclamados rápidamente. Como esto requiere espacio vacío para operar, el copying requiere mucha memoria en el montículo. La recolección copying se utiliza en todas las recolecciones menores. - Marcar y compactar (mark-compact): Este recolector permite a las generaciones ser recolectadas en el mismo lugar sin la reserva de memoria extra. Sin embargo, la compactación es significativamente más lenta que en el copying. - Incremental (también llamado train): Este recolector se usa sólo si se pasa en la línea de comandos -Xincgc. Mediante un registro cuidadoso, el recolector de basura recolecta solamente una porción de la generación vieja cada vez, distribuyendo cada recolección mayor en recolecciones más pequeñas. Esta estrategia disminuye el tiempo de cada ejecución del recolector de basura. Sin embargo, es más lenta que la anterior si consideramos el uso de procesador, es decir, la proporción del tiempo de funcionamiento del recolector de basura sobre el tiempo total de ejecución es mayor. Como el copying es muy rápido, sería bueno que la mayoría de los objetos se recolectasen mediante esta técnica en vez de las otras. La distribución por defecto de las generaciones se parece a la siguiente figura.



Figura 3: Generaciones en el montículo de Java

En la iniciación, se reserva virtualmente el máximo espacio de memoria, pero no se aloja memoria física hasta que no se necesita. El espacio completo de direcciones de memoria para los objetos se divide en las generaciones joven y vieja. La generación joven consiste en el edén más dos espacios de supervivientes. Los objetos se colocan inicialmente en el edén. Uno de los espacios de supervivientes está vacío en todo momento, y sirve como destino de la siguiente recolección mediante copying del edén y del otro espacio de supervivientes. Los objetos se copian entre los espacios de supervivientes de esta forma hasta que su edad es suficiente para ser poseídos (copiados a la generación vieja). Existen máquinas virtuales que utilizan dos espacios del mismo tamaño para el copying en vez de un edén y dos espacios de supervivientes más pequeños. La generación vieja es recolectada en el mismo lugar mediante mark-compact. Una porción llamada generación permanente es especial porque contiene los objetos que se refieren a la propia JVM, como los objetos class y method. En cuanto a las consideraciones de rendimiento, existen dos medidas primarias del rendimiento:

- Uso del procesador (throughput): Es el porcentaje de tiempo total no empleado en la recolección de basura considerada sobre largos períodos de tiempo. El uso de procesador incluye el tiempo empleado en el alojamiento de memoria (pero el ajuste de la velocidad de alojamiento no es generalmente necesario).

- Pausas (pauses): Son los períodos en que una aplicación no responde debido a que el recolector de basura está trabajando.

Algunos usuarios consideran estos otros dos parámetros:

- Footprint: es el conjunto de páginas y líneas caché para un proceso. En sistemas con memoria física limitada, o con muchos procesos, el footprint debe determinar la escalabilidad.

- Promptness: Es el tiempo transcurrido desde que el objeto muere hasta que se libera la memoria. Es un elemento importante para los sistemas distribuidos.

En general, la elección del tamaño de las generaciones busca un compromiso entre estos parámetros. Por ejemplo, una generación joven muy grande puede maximizar el tiempo de uso, pero a expensas del footprint y el promptness. Las pausas pueden minimizarse utilizando una generación joven pequeña y una recolección incremental, a expensas del tiempo de uso.



No hay reglas para determinar el tamaño de las generaciones. La mejor elección es determinada por la forma en que la aplicación utiliza la memoria y por los requerimientos del usuario. Los parámetros por defecto de la JVM para el recolector de basura no son óptimos para todas las aplicaciones.

2.5 APARTADO 5: Tarea propuesta. A continuación se detalla la Tarea propuesta a realizar por el alumno, se muestran las cinco preguntas del TEST propuesto y sus respuestas señaladas en color rojo: 1. Tareas esporádicas en RTS Java son: A) Las tareas se ejecutan cíclicamente durante un periodo de tiempo B) Las tareas que no cumplan con ciertos períodos, pero tienen una frecuencia máxima de ejecución. C) Tareas cuya frecuencia de rendimiento no se pueden predecir .. D) Las tareas con la prioridad más alta para su aplicación. 2. Indica que es una verdadera declaración relativa a los procesos y subprocesos: A) Cada subproceso en un proceso tiene una memoria separada. B) Los temas pueden comunicarse entre sí mediante una llamada al kernel del sistema operativo. C) Los procesos están aislados unos de los otros en términos de memoria y datos D) Los hilos tienen tres estados: New (nuevo), funcionamiento (ejecutable) y completo (muerto). 3. Especifique lo que se recomienda el tipo de memoria que se utilizará para tareas críticas A) Área de memoria convencional para aplicaciones (montón) B) La zona de la memoria secundaria C) El área de la memoria caché D) área de memoria inmortal 4. Indique cuál de las siguientes situaciones es aceptable en la comunicación entre los hilos (con cola), en términos de productividad. Supongamos que existe una cadena de tiempo real (RTT), que envía los datos a la cola, y otras



cadenas que "consumen" los datos. A) la cola se deja crecer sin restricción. B) Los datos de la cola deben ser borrados. C) String RTT, que envía los datos a la cola para ser bloqueados. D) RTT debe ser obligado a enviar más datos para colapsar la cola. 5. Indique cuál de los siguientes enfoques es utilizado por Java RTS para GC en tiempo real (RTGC) A) GC, basado en el algoritmo Henriksson B) GC, basado en el método de trabajo C) GC, basado en el método de tiempo D) GC convencional, utilizado por las aplicaciones en Java. LAS RESPUESTAS SON LAS SIGUIENTES: 1b, 2d, 3a, 4b, 5a

3. CONCLUSIONES La gestión automática de memoria en Java es muy útil, sin embargo, resta predictibilidad al sistema, aunque algunos algoritmos de recolección de basura (GC) son aplicables a determinados STR. RT-Java define extensiones al modelo de memoria, lo cual permite usar la memoria determinista. Los requisitos de la especificación de tiempo real son los siguientes:

- ser independiente de algoritmos particulares de GC - permitir una caracterización precisa del efecto del algoritmo concreto

implementado en el sistema sobre los threads (tiempo de ejecución, bloqueos)

- permitir creación y destrucción de objetos sin interferencia por parte del algoritmo de GC.

Los programadores de C++ pueden habituarse a Java rápidamente debido a la similitud de la sintaxis de ambos lenguajes. Además, para desarrolladores que no conozcan C++, Java tiene una curva de aprendizaje menor, por lo que constituye una buena apuesta para adentrarse en la programación orientada a objetos. En Java, cualquier reserva de memoria para los objetos se hace en el montículo de manera dinámica. Al haber sólo una forma de alojamiento de los objetos, se evitan posibles confusiones en la utilización del lenguaje, como ocurre con C++.



Java no tiene destructores de objetos. El recolector de basura se ocupa de todos los aspectos relacionados con la liberación de memoria. No todos los objetos pasan por todas las fases del ciclo de vida. Algunos incluso jamás serán recolectados. Por tanto no hay que pensar que todo objeto de Java será “destruido”, como ocurre en C++. Dentro de código Java se pueden incluir fragmentos de código en otros lenguajes (gracias a JNI). Estos lenguajes manejan la memoria de forma diferente a como lo hace Java. Para prevenir errores, se puede escribir dentro de Java un método llamado finalize(), que permite la limpieza de estos recursos de memoria, que escapan al control del recolector de basura. El recolector de basura es una gran ayuda a los programadores, pues les libera del trabajo de recuperar la memoria ocupada por objetos que ya no se utilizan. Esto tiene el inconveniente de que detiene la ejecución del programa en determinados momentos para efectuar la recolección. Sin embargo, merece la pena, pues abarata el coste de desarrollo y lo acelera. Aunque Java permita que el programador lleve a cabo ciertas operaciones de limpieza, será siempre más eficiente delegar la responsabilidad en el recolector de basura y no interferir con él. El recolector de basura dispone de diferentes algoritmos para la recolección, que dependen del tipo de objetos o de sus características, así como del estado de la memoria virtual. Hay una serie de parámetros del recolector de basura que permiten ajustar su funcionamiento de acuerdo con el tipo de aplicación que se esté desarrollando.

4. BIBLIOGRAFÍA Y/O REFERENCIAS

La bibliografía utilizada ha sido la siguiente: [1] Greg Bollella; Eric J. Bruno, REAL-TIME JAVA PROGRAMMING: WITH JAVA RTS (Primera edición), Ed. Prencite-Hall [2] Andrew J Wellings, CONCURRENT AND REAL-TIME PROGRAMMING IN JAVA (Primera edición), Ed. John Willey & Sons [3] Seminario de Electrónica: Sistemas embebidos, Facultad de Ingeniería (UBA). [4] Andrés Jesús Mesones Luque, Ingeniería en Informática, Universidad de Córdoba



5. ENLACES DE INTERÉS

Se detallarán los enlaces o links que puedan ser de interés en relación con el tema de Tarea 2-2: Sistemas operativos para Tiempo Real (RTOS). Java (RTSJ) como RTOS

http://www.rtsj.org/specjavadoc/book_index.html http://eprints.ucm.es/8949/1/TC_2006-20.pdf http://isa.uniovi.es/docencia/TiempoReal/Recursos/Transparencias/RTJava.pdf http://zarza.usal.es/~fgarcia/docencia/poo/01-02/trabajos/S3T6.pdf

http://www.rtsj.org/specjavadoc/book_index.html

http://eprints.ucm.es/8949/1/TC_2006-20.pdf

http://isa.uniovi.es/docencia/TiempoReal/Recursos/Transparencias/RTJava.pdf

http://zarza.usal.es/~fgarcia/docencia/poo/01-02/trabajos/S3T6.pdf

master degree: industrial systems engineering...que los requisitos de temporización, para no...

Documents