Curso:Industria y comunicaciones en Tiempo-Real. Módulo2 – Sistemas en Tiempo-Real.

1. 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. AntonPetrov - Departamento ECIT en PU - Plovdiv.

2. TemasPrincipales Requisitos básicos para OS en tiempo real (RTOS) Características de Java como un sistema operativo (RTSJ y Java RTS) de tiempo real Procesos y subprocesos Tipos de áreas de memoria de la RTSJ Mejora de la comunicación entre hilos en RTSJ Garbage Collector (GC) en los sistemas de tiempo real - enfoques Garbage Collector (GC) En Java RTS

3. 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.

4. Requisitos básicos para OS en tiempo real(2) • Los requisitos básicos se pueden resumir de la siguiente manera: • 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 • 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. • 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 programa de manejo del sensor puede acceder a él.

5. 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 también asociado a cada hilo.

6. 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.

7. Algunosejemplos 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

8. Características de Java como RTOS • Java soporta paralelismos relativamente débiles (hilos y los métodos de sincronización) y se puede utilizar para algunos RTS débiles. • 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.

9. 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.

10. 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

11. 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

12. 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

13. 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

14. Procesos e hilos. • Ambos temas y procesos son los métodos de paralelizaciónde 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

15. Diferencia entre los losprocesos 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

16. 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.

17. Condiciones de hilosusados 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 + +

18. Condiciones de hilosusadosen 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).

19. Prioridades de hilosenRTSJ (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.

20. Prioridades e hilos enRTSJ(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.

21. Prioridades e hilos enRTSJ(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.Threador 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.

22. Tipos de memoria y suuso 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)

23. Tipos de memoria y suuso 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.

24. 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.

25. 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.

26. Las fuentes de incertidumbre en la aplicaciónJava(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.

27. Recolector de Basura (GC) en sistemas en Tiempo- Real. • 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.

28. 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 pide la memoria para un objeto.

29. 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.

30. Recolector de Basura (GC) en laRTSJ (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.

31. Recolector de Basura (GC) en laRTSJ(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

34. 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

35. References http://java.sun.com/javase/technologies/realtime/index.jsp http://jcp.org/aboutJava/communityprocess/mrel/jsr001/index2.html http://www.timesys.com/java/