Download Sistemas en Tiempo Real (RTS)

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)
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
2
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
3
Sistemas en Tiempo Real (RTS)
-
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
relativos).
deadlines
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).
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
4
Sistemas en Tiempo Real (RTS)
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
5
Sistemas en Tiempo Real (RTS)
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
-
Basado en Linux
RTLinux
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:
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
6
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
7
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
8
Sistemas en Tiempo Real (RTS)
-
-
-
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
9
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
10
Sistemas en Tiempo Real (RTS)
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,
decir, el programador asigna una prioridad a cada proceso, de los cuales
ejecuta siempre el proceso de mayor prioridad, entre los que están listos.
aparece uno de mayor prioridad, se interrumpe la ejecución y se le da
control
es
se
Si
el
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:
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
11
Sistemas en Tiempo Real (RTS)
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:
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
12
Sistemas en Tiempo Real (RTS)
-
-
Ser independiente de cualquier algoritmo de recolección de basura
particular.
Permitir al programa caracterizar de forma precisa el efecto de
algoritmo de recolección de basura sobre el tiempo de ejecución,
prioridades, y el envío de los hilos Java en tiempo real.
Permitir la ubicación de objetos sin interferencia de ningún algoritmo
recolección de basura
en
un
las
de
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
13
Sistemas en Tiempo Real (RTS)
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á
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
14
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
15
Sistemas en Tiempo Real (RTS)
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
o
-
a. Scoped constante: que requiere que el tiempo de asignación
sea directamente proporcional al tamaño del objeto que está
siendo asignado.
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
16
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
17
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
18
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
19
Sistemas en Tiempo Real (RTS)
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.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
20
Sistemas en Tiempo Real (RTS)
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)
B)
C)
D)
Área de memoria convencional para aplicaciones (montón)
La zona de la memoria secundaria
El área de la memoria caché
á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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
21
Sistemas en Tiempo Real (RTS)
cadenas que "consumen" los datos.
A)
B)
C)
D)
la cola se deja crecer sin restricción.
Los datos de la cola deben ser borrados.
String RTT, que envía los datos a la cola para ser bloqueados.
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)
B)
C)
D)
GC, basado en el algoritmo Henriksson
GC, basado en el método de trabajo
GC, basado en el método de tiempo
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++.
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
22
Sistemas en Tiempo Real (RTS)
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
23
Sistemas en Tiempo Real (RTS)
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
SISTEMAS OPERATIVOS PARA TIEMPO REAL (RTOS). JAVA (RTSJ) COMO RTOS
24