Download procesos

Curso:Industria y comunicaciones
en Tiempo-Real.
Módulo2 – Sistemas en Tiempo-Real.
Tarea 3: Elección de los OS en Tiempo-Real.
Java como un OS en Tiempo-Real.
Desarrollado por el profesor Manuel Castro - UNED Madrid. Adaptado y
complementado por el Prof. Anton Petrov - Departamento ECIT en PU - Plovdiv.
Temas Principales
1.Requisitos básicos para OS en tiempo real (RTOS)
2.Características de Java como un sistema operativo (RTSJ y Java
RTS) de tiempo real
3.Procesos y subprocesos
4.Tipos de áreas de memoria de la RTSJ
5.Mejora de la comunicación entre hilos en RTSJ
6.Garbage Collector (GC) en los sistemas de tiempo real - enfoques
7.Garbage Collector (GC) En Java RTS
2
Requisitos básicos para OS en tiempo real (1)
 La elección del sistema operativo de tiempo real (RTOS) es esencial para la
determinación total de RTS, para saber: la funcionalidad, el rendimiento, la
fiabilidad, tiempo de espera y el precio en el mercado.
 El diseño de los sistemas de alta fiabilidad es un proceso más difícil y
responsable y requiere una cuidadosa elección del sistema operativo. Cuando
el propio RTOS proporciona al usuario mecanismos para la aplicación del alto
nivel de protección y seguridad en el uso y manejo de los recursos del sistema,
este proceso puede ser facilitado considerablemente.
 En los sistemas con una alta fiabilidad, hilos, dedicados al procesamiento y
visualización de datos (interfaz de usuario) compiten con los hilos que realizan
el seguimiento de los parámetros críticos y las condiciones de alarma, y los
hilos responsables de toma de decisiones y la conducción de diferentes
mecanismos. Se trata de una "lucha" por tiempo y recursos del sistema.
 Para ser capaces de coexistir hilos de distintos grados de importancia en la
misma aplicación, el sistema operativo debe garantizar una adecuada
asignación de tiempo de CPU y otros recursos para garantizar su
disponibilidad en cualquier momento dado.
3
Requisitos básicos para OS en tiempo real(2)
 Los requisitos básicos se pueden resumir de la siguiente manera:
1. Protección de la memoria. La tolerancia de errores, y por lo tanto la
fiabilidad de un sistema dependen principalmente en los métodos de
protección de memoria
2. La tolerancia de errores y accesibilidad. Incluso el mejor software tiene,
errores latentes ocultos. Para este propósito RTOS debe proporcionar
mecanismos para la detección de errores y recuperación. OS debe elegir la
forma más adecuada para reaccionar - la posibilidad de reiniciar el sistema o
no: si una interfaz de usuario se puede reiniciar, el programa para la gestión
de los aviones no puede.
3. Derechos de acceso a los recursos del sistema. Hay dos tipos principales
de los derechos de acceso necesarios - y siempre que. Un ejemplo del
segundo tipo son los derechos de acceso a un archivo - un proceso o hilo
puede permitir el acceso a archivos a otro proceso en el sistema. En los
sistemas que requieren alta fiabilidad y seguridad no es posible, y no debe ser
aplicado el tipo requerido de derechos de acceso a los objetos de sistema
críticos. Ejemplo: sensor para controlar un parámetro (por ejemplo, el nivel de
radiación) del medio ambiente en la planta de energía nuclear - el
desarrollador del sistema debe establecer los derechos y resolvió que sólo el
4
programa de manejo del sensor puede acceder a él.
Requisitos básicos para OS en tiempo real(3)
4. Acceso a la capacidad de memoria Garantizado. Para los sistemas críticos,
la fiabilidad es esencial para los procesos de fundamental importancia, tener
siempre memoria para recursos deseados. En la mayoría de RTOS, la memoria
para mantener el bloqueo de control de cada hilo u otros objetos es asignado
por un recurso central común. Esta situación para las aplicaciones críticas no
debe permitirse. Para garantizar la memoria siempre disponible, RTOS debe
proporcionar un mecanismo para la asignación de cuotas de memoria de
acuerdo con las prioridades de los distintos procesos.
5. Garantizar el acceso a los recursos "tiempo de CPU '. La mayoría de RTOS
se usa en principios de prioridad para la asignación de tiempo de CPU. En este
esquema, el hilo con la prioridad más alta obtiene el tiempo de ejecución de
CPU. Tener más de un hilo con la misma prioridad, se emplea para el principio
de tiempo compartido, que se proporcionan a cada hilo por igual..
6. Respuesta rápida del sistema. En aplicaciones de alta seguridad es
extremadamente importante para evaluar los parámetros temporales del
sistema, es decir, para determinar su rendimiento. No sólo el tiempo de
conexión, también el tiempo que RTOS ejecuta el código de programa de los
hilos individuales que deben ser calculados, pero solo el tiempo adicional
5
también asociado a cada hilo.
Requisitos básicos para OS en tiempo real(4)
 Para un pequeño sistema operativo para objetos relativamente simples y no
muy responsable, no hay hardware específico para la protección de la
memoria. Con las crecientes necesidades de aplicaciones modernas para los
sistemas integrados, están aumentando los requisitos para RTOS en términos
de margen de error, la disponibilidad de recursos, el rendimiento y la fiabilidad
de los sistemas. Por tanto, la elección del sistema operativo de tiempo real, que
será implementado en una aplicación, sus requisitos serán complejos, sobre
todo porque el mercado tiene un gran número de RTOS.
 Al elegir un sistema operativo en tiempo real, es necesario prestar atención
al objeto en el que están integrados en términos de escalabilidad, seguridad y
fiabilidad, etc. Así, por ejemplo, los objetos pequeños con sistemas integrados
MP tales como GSM, electrodomésticos, dispositivos de mano, etc. Los
sistemas operativos más utilizados, como Symbian, Itron, Android, Palm y
otros. mientras que para los sitios grandes con requisitos de alta fiabilidad,
como las centrales nucleares, militares y equipos aeroespaciales, equipos de
control médico en casos de emergencia y mucho más, requieren más
sofisticación y bien organizados sistema operativo en tiempo real.
6
Algunos ejemplos de RTOS
 Un primer ejemplo de un sistema operativo en tiempo real a gran escala fue el
Transaction Processing Facility desarrollado por American Airlines e IBM para
el sistema Sabre Airline Reservations.
 En la actualidad el más conocido, de mayor despliegue, de sistemas operativos
de tiempo real son::

LynxOS

OSE

QNX

RTLinux

VxWorks

Windows CE

RTS Java и др.
 Lista completa RTOS y su aplicación se puede ver en :
http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
7
Características de Java como RTOS
 Java soporta paralelismos relativamente débiles (hilos
sincronización) y se puede utilizar para algunos RTS débiles.
y
los
métodos
de
 Java 2.0 no es adecuado para un fuerte RTS pero ahora hay nuevas versiones de Java
de tiempo real que solucionan y superan problemas como:
– Si no se especifica el tiempo de ejecución de un hilo;
– Tiempo diferente para su ejecución en diferentes máquinas virtuales;
– Liberación incontrolada de memoria (recolección de basura);
– Inaccesibilidad del hardware del sistema
– Incapacidad para analizar el espacio y el rendimiento, y más.
8
Tiempo de tareas y metas en RTSJ
 RTSJ Modela la parte de tiempo real de una aplicación como un conjunto de
tareas, cada una de las cuales tiene como objetivo la libre elección del tiempo .
Este objetivo determina cuando se debe completar la tarea. Tareas en tiempo
real se dividen en varias categorías dependiendo de cómo el desarrollador
puede predecir la frecuencia e implantación:
– Periódicos: Las tareas se ejecutan cíclicamente durante un período de
tiempo, tales como la lectura de un sensor cada 5 milisegundos.
– Esporádica: tareas que no cumplan con ciertos períodos, pero tienen una
frecuencia máxima de ejecución.
– Aperiódica: tareas cuya frecuencia de funcionamiento no se puede predecir.
 RTSJ utiliza información de dos tipos de tareas de diferentes maneras para
asegurar que las tareas críticas cumplan con sus objetivos. En primer lugar,
permite la asociación de cada tarea un controlador de las metas no cumplidas.
Si una tarea no se completa dentro del objetivo de tiempo, el controlador
adecuado es llamado. Información de fallo se puede utilizar para tomar
medidas correctivas o para proporcionar información sobre la eficacia o el
comportamiento caótico de un usuario o una aplicación de gestión.
9
Procesos e hilos en el contexto de OS
 Antes de proceder a las preguntas sobre los procesos e hilos en Java
RTS recordemos estos conceptos del curso "Introducción a los Sistemas
Industriales"
 Proceso es parte de un programa o un programa completo en acción.
Cada proceso tiene una tarea específica que hacer y necesita algunos
recursos, incluyendo tiempo de CPU, memoria, archivos y dispositivos I /
O
 Las cinco actividades principales del sistema operativo sobre la gestión de
procesos son :
 Crear y eliminar procesos de usuario y del sistema.
 Cese y reanudación de procesos.
 Mecanismo para la sincronización de los procesos.
 Mecanismo para la comunicación entre procesos.
 Mecanismo de procesamiento de "deadlock"
en caso de producirse
10
10
Gestión de Procesos – 1
 En la clásica arquitectura de computadores de von Neumann sólo un
proceso en una CPU puede tener lugar en un momento. Modernos
sistemas operativos permiten la ejecución simultánea de varios procesos a
través del modo multitarea, incluso con una CPU.
 Cuando los equipos contienen una CPU, el modo multitarea es
implementado para cambiar rápidamente entre procesos.
 En sistemas con múltiples CPU, las tareas y procesos se distribuyen
entre los procesadores y el sistema operativo se encarga de manera
uniforme sobre la carga de la CPU.
El proceso se define por un cierto conjunto de instrucciones de
programa y estados.
11
11
Gestión de Procesos– 2
 El estado de un proceso se define como un mínimo los siguientes
elementos :
 El código de programa.
 Programa de datos estáticos y dinámicos.
 Programa stack de llamadas a procedimientos.
 Contenido del registros de propósito general.
 Contenido del contador de programa (PC)
 El contenido de la palabra de estado del programa (PSW).
 Recursos utilizados del sistema operativo.
 Cada proceso puede crear nuevos procesos.
12
12
Estado de Procesos.
 Cada proceso pasa a través de una serie de estados discretos :
 Nuevo Estado - cuando se crean los procesos.
 Ejecución de Estado - el proceso está en funcionamiento, el
uso de CPU y otros recursos.
 Bloqueado o estado de espera - los procesos está bloqueado
o esperar a la finalización de la operación de otro proceso, los
recursos, etc.
 Estado Ready - los procesos está listo para su ejecución y
esperar la CPU para liberarse de otro proceso, y para obtener el
tiempo de que.
 Estado Terminado - la implementación del proceso es
completa.
13
13
Procesos e hilos.
 Ambos temas y procesos son los métodos de paralelización de una
aplicación. Sin embargo, los procesos de las unidades de ejecución son
independientes, estos contienen su propia información de estado, utilizan sus
propios espacios de direcciones, y sólo interactúan entre sí a través de
mecanismos de comunicación entre procesos (generalmente gestionados por el
sistema operativo). Las solicitudes se suelen dividir en procesos durante la fase de
diseño, y un proceso maestro explícita generación de hilos cuando tiene sentido a
la funcionalidad de la aplicación significativa lógicamente separada. Procesos, en
otras palabras, son una construcción arquitectónica.
 Por el contrario, un hilo es una construcción de codificación que no afecta a la
arquitectura de una aplicación. Un solo proceso puede contener varios
subprocesos; todos los temas de un proceso comparten el mismo estados y en
el mismo espacio de memoria, y puede comunicarse directamente entre sí, ya
que comparten las mismas variables.
 Los hilos se utilizan para tareas pequeñas, mientras que los procesos se
utilizan para tareas más "pesadas" - básicamente la ejecución de
aplicaciones.
14
14
Diferencia entre los los procesos e hilos.
He aquí un resumen de las diferencias entre los procesos e hilos :
1. Los hilos son fáciles para crear procesos, ya que no requieren un
espacio de direcciones independiente.
2. Multihilos requiere una cuidadosa programación desde hilos que
comparten estructuras de datos que sólo deben ser modificados por un
hilo a la vez. A diferencia de subprocesos, los procesos no comparten el
mismo espacio de direcciones.
3. Hilos se consideran ligeros porque utilizan muchos menos recursos
que los procesos.
4. Los procesos son independientes entre sí. Hilos, puesto que
comparten el mismo espacio de direcciones son interdependientes, por lo
que se debe tener cuidado para que los diferentes subprocesos no pisen
entre sí. Esto es realmente otra forma de decir # 2 arriba.
5. Un proceso puede consistir en múltiples hilos.
15
15
Ventajas de los hilos.

Se necesita menos tiempo para la creación y terminación de un hilos que
de un proceso

El cambio entre dos hilos lleva menos tiempo que el cambio entre dos
procesos

Hilos pueden comunicarse entre sí sin la llamada del núcleo

El uso de múltiples hilos crea una impresión de la multitarea. La razón es
que el tiempo de un subproceso toma de CPU es muy corto
Casos en los que es conveniente utilizar hilos :

Servicio para muchos usuarios a la vez, como por ejemplo un servidor Web

La comunicación a través de la red (sockets)

Realice la operación que consume tiempo

La distinción entre las tareas por prioridad

Para que la interfaz de usuario pueda continuar para "responder" a
consultas de los usuarios, mientras que se lleva a cabo la tarea de fondo.
16
Condiciones de hilos usados en Java
 Características de los hilos en Java
Los subprocesos en Java son objetos de la clase Thread, que es parte del
paquete java.lang.
Al crear un nuevo subproceso es necesario redefinir el método run (), toda la
funcionalidad del subproceso está insertado en este método.
El método run () puede llamar a otros métodos.
El subproceso se inicia mediante una llamada al método del objeto start ().
El método start (), a su vez llama al método run () y se encarga de la
realización de las tareas adicionales requeridas.
 Ninguno de estos métodos tiene ningún parámetro.
 En un programa puede usar muchas diferentes clases Thread y muchos
otros objetos la misma clase Thread.
 Cada una de estas clases tiene su propio método run () que es
independiente de la run () para métodos de otras clases.
* Requires some knowledge of programming in Java or C + +
17
Condiciones de hilos usados en Java
Condiciones de hilos Java
 El estado del subproceso muestra lo que hace actualmente y lo que es capaz de
realizar. Se puede estar en cuatro estados: New (Nuevo), running (Runnable),
broken ​/ blocked (Bloqueado) y completed (Dead) (ver figura siguiente).
18
Prioridades de hilos en RTSJ (1)
 Prioridades de hilos en Java
Establecer la prioridad de los hilos puede ser muy útil si uno de ellos tiene que
realizar tareas más importantes que otros. Clase Thread tiene un setPriority
método (int level), gracias al cual se puede cambiar la prioridad. Parámetro de
nivel puede tener cualquier valor entre 1 (el menos importante) a 10 (el más
importante), y si el nivel no está establecido, sea pts defecto es 5.
En RTOS las prioridades de hilos son de gran importancia. Ningún sistema
puede garantizar que todas las tareas se completan a tiempo. Sin embargo, un
RTOS puede garantizar que si algunas tareas no pueden cumplir con los
objetivos de tiempo, entonces las tareas de menor prioridad se ejecutará primero.
RTSJ define al menos 28 niveles de prioridad y exige el cumplimiento
estricto. Sin embargo, tiene funciones de apoyo a múltiples prioridades.
19
Prioridades e hilos en RTSJ(2)
 Reorganización de prioridades podría afectar negativamente al
rendimiento. Por lo tanto, la requiere prioridad heredada en su gestión.
Esto evita que el cambio de prioridades, el aumento de la prioridad de los
hilos de bloqueo en un recurso con el fin de adaptar sus prioridades a este
subproceso de mayor prioridad de espera para el recurso.
Esto evita el tiempo de espera infinito de un hilo con mayor prioridad que
hilos con una prioridad más baja, que bloquea un recurso, pero no puede
liberar porque no recibe los ciclos necesarios de la CPU, para completar la
tarea.
20
Prioridades e hilos en RTSJ(3)
 RTSJ permite acciones en tiempo real e irreal-tiempo en la misma aplicación
Java. El grado de garantías temporales depende del tipo hilos que se ejecutan:
java.lang.Thread or javax.realtime.RealtimeThread.
 El subproceso común, java.lang.Thread (JLT), se utilizan para las acciones
de tiempo irreal. Ellos pueden usar 10 niveles de prioridad, pero no estén
vinculadas por garantizar el tiempo de ejecución.
 Hilos en tiempo real, javax.realtime.RealtimeThread (RTT), son compatibles
con las prioridades de la gestión Se ha conseguido llevar a los bloques de
prioridad, en lugar de utilizar la distribución de los intervalos de tiempo (tiempo
compartido). Es decir administrador de subprocesos realizará único contexto que
cambia cuando un RTT de mayor prioridad está listo para funcionar.
 RTSJ proporciona una subclase de hilos por RTT, llamado
NoHeapRealtimeThread (NHRT). Las instancias de esta subclase están
protegidos de la interferencia de GC, como hilos NHRT están diseñados para las
actividades en tiempo real rígidos.
21
Tipos de memoria y su uso en la función RTSJ(1)
 RTSJ ofrece diversas formas de para reservar áreas de la memoria para
un objeto de acuerdo con el tipo de la tarea. Las diferentes áreas tienen
diferentes características respecto a la GC * y diferentes límites para
reservation.RTSJ soporta los siguientes tipos de memoria:
– Pila estándar. Cada máquina virtual mantiene, RTJS mantiene un
heap con su propio GC, que se puede utilizar los hilos o hilos estándar
para tiempo real. NHRT no puede utilizar montón standar para
garantizar la previsibilidad (RTJS proporciona una subclase de hilos
RTT, llamado NoHeapRealtimeThread - NHRT).
* CG - Garbage Collector - "Cleaner" of memory (see details in
task_3_specific_trainingB.doc)
22
Tipos de memoria y su uso en la función RTSJ(2)
– Inmortal Memory. Memoria inmortal es parte de la memoria que no
tiene un GC. Cuando un objeto se le asigna en la memoria inmortal, la
memoria utilizada por el objeto nunca será liberada. El principal uso de
la memoria inmortal es permitir que procesos eviten las actividades de
mantenimiento DRAM, conservando la memoria estática, que es
necesaria antes de la implementación y gestión de ellos mismos.
Gestión de memoria inmortal requiere mucha más atención que
estándar.
– Limited memory. Estas áreas de memoria están diseñados para
objetos con tiempos de vida conocidas como objetos temporales
creados durante el procesamiento de una tarea. Y no tiene GC, pero el
área total de la memoria se puede reutilizar o se libera tras la
finalización de la tarea que utiliza ese espacio. Estas áreas tienen un
límite máximo establecido para el control del uso y el crecimiento.
23
Las fuentes de incertidumbre en la aplicación Java (1)
 Hay diferentes factores que conducen a la incertidumbre en el tiempo de
ejecución de las aplicaciones, por lo que puede hacer que la aplicación
Java estándar no cumple con los objetivos de tiempo. Las razones
más comunes son :
 El sistema operativo. Los subprocesos en Java son creadas por la JVM (Java
Virtual Machine), pero administrados por el sistema operativo. Con el fin de
garantizar la JVM latencia, el sistema operativo debe garantizar latencia para la
gestión de sus subprocesos.
 Intercambiar prioridades. Si de un subproceso con una prioridad más baja
(TLP) comparte un recurso con otro subproceso de mayor prioridad (THP), y si
el recurso está sincronizado con el monitor, TLP puede bloquear el recurso
cuando el THP lo necesita. En este caso THP no puede continuar, hasta que se
terminó la TLP de trabajo y esto puede provocar el fallo de los objetivos
temporales THP.
24
Las fuentes de incertidumbre en la aplicación Java(2)
 Cargando clases, inicialización y compilación. Cuando se inicializa
la clase con el código de usuario, esto puede crear una gran
inestabilidad. Desde clases de carga pueden requerir acceso a disco o
de red de búsqueda de una definición de esta clase, esto puede
causar retrasos inesperados (y superior).
 Recolector de basura. La principal fuente de incertidumbre en las
aplicaciones de Java es recolector de basura. Algoritmos de GC utiliza
el estándar de JVM, incluido en una forma u otra, la suspensión de
todos los hilos, de modo que el GC para poder trabajar sin
interrupciones. En sistemas de tiempo real no pueden tolerar los
descansos.
25
Las fuentes de incertidumbre en la aplicación Java(3)
 Aplicación. La propia aplicación también utiliza diferentes bibliotecas y
actividades que requieren recursos de la CPU y puede traer
incertidumbre. En NRW número de aplicaciones del lado es muy
limitada.
 Otras actividades en el sistema. Puede haber otras actividades de
mayor prioridad en el sistema, las interrupciones de hardware, otras
aplicaciones en tiempo real y más. Estas otras actividades pueden
intervenir y por lo tanto afectar al rendimiento de la sincronización.
 En RTSJ están buscando maneras de minimizar esta incertidumbre :
mejor gestión de la memoria, mejorar la comunicación entre hilos y
diferentes algoritmos para la planificación de la GC en tiempo real, que
se discutirá más adelante.
26
Recolector de Basura (GC) en sistemas en TiempoReal.
 Dado que el recolector de basura del sistema es una de las principales fuentes de
incertidumbre en las aplicaciones Java, la máquina virtual de tiempo real (VM) debe
encontrar una forma de evitar las interrupciones causadas por el GC, lo que provoca errores
en la consecución de objetivos de tiempo. Sin embargo, cabe señalar que la memoria
descriptiva en RTSJ no define explícita la generación de la especificación de tiempo real
GC.
 Existen varios enfoques para la planificación de la GC en entornos en tiempo real,
cada uno con sus propias ventajas y desventajas. Esto incluye dos enfoque específico
basado en el trabajo y en función del tiempo. Estos dos métodos se utilizan para
minimizar los efectos de la GC en la planificación de subprocesos.
 Aunque ambos enfoques reducen la duración GC y mejorar la previsibilidad de
perturbaciones específicas que pueden ser difíciles de usar y sincronizar con el entorno de
trabajo, lo que reduce su fiabilidad cuando se usa para los sistemas de tiempo real rígidos.
 Hay un tercer enfoque, llamado el enfoque Henriksson.
27
Recolector de Basura (GC) en el sistema de Renaldo
Vreme(1)
 Existen varios enfoques para la planificación de la GC en entornos en
tiempo real, cada uno con sus propias ventajas y desventajas. Esto incluye dos
enfoque específico basado en el trabajo y en función del tiempo. Estos dos
métodos se utilizan para minimizar los efectos de la GC en la planificación de
subprocesos.
 A) Un enfoque basado en el trabajo
 Este modelo requiere que cada hilo realiza una parte del crecimiento de
trabajo específico GC siempre que se necesite memoria para un objeto. Este
enfoque tiene algunas características positivas de equilibrio en el sentido de
que las actividades que requieren más memoria para los objetos están en
mayor riesgo de CG, en comparación con aquellos que "gastan" menos
objetos.
 Desventajas: como el tiempo requerido para realizar una cierta cantidad de
trabajo por GC varía, es difícil predecir el efecto de GC en la planificación,
es decir, alta tarea de prioridad puede no realiza los objetivos temporales si se
28
pide la memoria para un objeto.
Recolector de Basura (GC) en el sistema de Renaldo
Vreme(2)
 B) Un enfoque basado en el tiempo
 En lugar de dividir el trabajo de GC a las crecientes peticiones de cobro, el
enfoque basado en el tiempo, tiene previsto un período de tiempo de GC para
cada período de programación. Esto iguala el costo de implementación de GC
con otras actividades en el programa. Una vez más no hay ningún vínculo entre
la cantidad de tiempo aumenta en la ejecución de GC y la cantidad de memoria
que se requiere, de modo que el enfoque en tiempo real para el problema
puede ser similar al enfoque basado en el trabajo.
 Aunque ambos enfoques reducen la duración GC y mejorar la previsibilidad
interrupciones específicas, puede ser difícil de usar y sincronizarlos con el
entorno de trabajo, lo que reduce la fiabilidad cuando se utilizan para
sistemas de tiempo real rígidos (duro).
 C) Existe un tercer método llamado enfoque Henriksson, que consiste en la
modificación del enfoque basado en el trabajo de manera que el creciente uso de
GC, la memoria de consulta relacionada con hilos críticos se posponen hasta que
un mensaje ha hecho su trabajo.
29
Recolector de Basura (GC) en la RTSJ (1)
 D) La recolección de basura (GC) de tiempo real realizada por el
RTSJ from Sun (Java RTS)
 El sistema de GC para tiempo real por Java from Sun (Java RTS),
http://java.sun.com/javase/technologies/realtime/
,es
una
implementación comercial de la Especificación de tiempo real para
Java
(),
es
decir,
la
especificación
JSR
1,
http://jcp.org/en/jsr/detail?id=1.
 La realización de la versión 2.0 de Sun, Java RTS 2.0, proporciona
un nuevo Tiempo real GC (RTGC), que utiliza el algoritmo de
Henriksson. El GC realiza una o más subprocesos para tiempo real
(RTT). Ellos se cumplen con una prioridad más baja que todos los
otros casos NoHeapRealtimeThread (NHRT), y puede ser menor que
la prioridad algunos de los subprocesos RTT, de tal manera que las
tareas críticas se pueden interrumpir GC y el uso de la CPU. Por lo
tanto subprocesos críticos están protegidos de los efectos de la GC.
30
Recolector de Basura (GC) en la RTSJ(2)
 En algoritmo RTGC está configurado la prioridad máxima GC. Esto
divide la prioridad en dos filas. subprocesos NHRT reciben la más alta
prioridad y se conocen como las tareas críticas. La siguiente prioridad
son subprocesos en tiempo real (RTT), seguido de subprocesos que no
son críticas para en tiempo real y, finalmente, las tareas que no son en
tiempo real. Como estándar, GC se hace con su prioridad que es menor
que la de subprocesos que no son críticas para tiempo real. Sin
embargo, dependiendo de si memoria se vuelve insuficiente (es decir,
reduce la memoria disponible), JVM reduce o aumenta la prioridad de la
GC a su máxima prioridad
31
32
33
Checklist
 Utilizando material de Internet, haga una breve descripción y
comparación de sistema operativo de tiempo real. ¿De dónde viene
RTSJava encajar entre otros sistemas operativos en tiempo real?
 Explicar los conceptos de "prioridades" y los "subprocesos" que se
utiliza en el sistema en tiempo real Java.
 Explora los tipos de memoria y su uso en RTS de Java. ¿Cómo funciona
etc recolector de basura?
 Haga la prueba dada en Task3 definición, como en la respuesta
especifica respuestas correctas en forma de muestra: 1A, 2C ... etcétera
34
References
http://java.sun.com/javase/technologies/realtime/index.jsp
http://jcp.org/aboutJava/communityprocess/mrel/jsr001/index2.html
http://www.timesys.com/java/
35