Download Industria y comunicaciones en Tiempo-Real

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:
Industria y comunicaciones en Tiempo-Real
MÓDULO 2:
Sistemas en Tiempo-Real
TAREA 2-2:
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPOREAL
Industria y comunicaciones en Tiempo-Real
Contenido
TAREA 2-2: ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO
REAL. .................................................................................................................................................................................................3
1. INTRODUCCIÓN Y OBJETIVOS ...........................................................................................................................3
2. CONTENIDO .....................................................................................................................................................................3
2.1 REQUISITOS BASICOS PARA OS EN TIEMPO-REAL ......................................................................3
2.2 ALGUNOS EJEMPLOS DE RTOS.................................................................................................................6
2.3. CARACTERÍSTICAS DE JAVA COMO RTOS ........................................................................................7
2.4. TIEMPO DE TAREAS Y METAS EN RTSJ .............................................................................................8
2.5. PROCESOS E HILOS (THREAD) EN EL CONTEXTO DE OS ...................................................8
2.6. PROCESOS E HILOS ......................................................................................................................................11
2.7 DIFERENCIA ENTRE PROCESOS E HILOS ..........................................................................................12
2.8. VENTAJAS DE LOS HILOS .........................................................................................................................13
2.9. CONDICIONES DE HILOS USADOS EN JAVA ...............................................................................14
2.10. PRIORIDADES DE HILOS (THREADS) EN RTSJ ...........................................................................16
2.11. TIPOS DE MEMORIA Y SU USO EN LA FUNCIÓN RTSJ ...................................................17
2.12. LAS FUENTES DE INCERTIDUMBRE EN LA APLICACIÓN JAVA .......................................18
2.13. RECOLECTOR DE BASURA (GC) EN SISTEMAS EN TIEMPO-REAL................................19
3. CONCLUSIONES .........................................................................................................................................................23
4. BIBLIOGRAFÍA Y/O REFERENCIAS ...................................................................................................................23
5. ENLACES DE INTERÉS ............................................................................................................................................23
Índice de figuras
Figura
Figura
Figura
Figura
Figura
1:
2:
3:
4:
5:
HILOS (THREADS)...........................................................................................................................................11
ESTADO DE LOS HILOS ............................................................................................................................15
GC BASADOS EN EL TRABAJO ............................................................................................................23
GC BASADOS EN EL TIEMPO ................................................................................................................23
GC HENRIKSSON ..........................................................................................................................................24
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
2
Industria y comunicaciones en Tiempo-Real
TAREA 2-1: FUNDAMENTO Y PROGRAMACIÓN DE
SISTEMAS EN TIEMPO-REAL.
1. INTRODUCCIÓN Y OBJETIVOS
En esta tarea nuestro objetivo principal será conocer las características de los
OS en Tiempo-Real (RTSO), así como sus ventajas respecto a un OS sin
Tiempo-Real.
En especial estudiaremos las características de Java como RTSO.
2. CONTENIDO
2.1 REQUISITOS BASICOS PARA OS EN TIEMPO-REAL
Un sistema operativo para tiempo real es un sistema operativo capaz de
garantizar los requisitos temporales de los procesos que controla.
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
Los sistemas operativos convencionales no son apropiados para la realización
de sistemas de tiempo real, debido a que
– no tienen un comportamiento determinista y
– no permiten garantizar los tiempos de respuesta.
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.
Un sistema operativo para tiempo real debe ofrecer las siguientes facilidades:
– concurrencia: procesos ligeros, hilos (threads) con memoria compartida.
– temporización: medida de tiempos y ejecución periódica.
– planificación: prioridades fijas con desalojo, acceso a recursos con
protocolos de herencias de prioridad.
– dispositivos de E/S: acceso a recursos hardware e interrupciones.
Para ser capaces de coexistir hilos de distintos grados de importancia en la
misma
aplicación,
el
sistema
operativo
debe
garantizar
una
adecuada
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
3
Industria y comunicaciones en Tiempo-Real
asignación
de
tiempo
de
CPU
y
otros
recursos
para
garantizar
su
disponibilidad en cualquier momento dado.
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 programa de manejo del
sensor puede acceder a él.
4. 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. 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
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
4
Industria y comunicaciones en Tiempo-Real
prioridad, se emplea para el principio de tiempo compartido, que se
proporcionan a cada hilo por igual..
6. 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.
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.
Problemas de los sistemas operativos convencionales:
• Existen algunas características de los sistemas operativos convencionales que
impiden su uso como RTOS (Real-Time Operating System).
• Lo veremos en el caso particular de un sistema operativo UNIX.
• Problemas:
1- Planificación para tiempo compartido:
• Uso de planificadores que aseguran un uso equitativo del tiempo de
CPU entre todos los procesos.
• Es conveniente para un usuario que usa el sistema desde una terminal.
• No para procesamiento de tiempo real, ya que la ejecución de
cualquier proceso depende de forma compleja e impredecible de la
carga del sistema y el comportamiento del resto de procesos.
2-
Baja resolución del temporizador:
• Históricamente a los procesos de usuario se les proporcionaban
señales de alarma y la llamada al sistema sleep() con sólo 1 segundo
de resolución Þ No es suficiente para procesamiento de tiempo real.
• Las versiones más modernas proporcionan medios de especificar
intervalos con mayor precisión.
Problemas (cont.):
3-
Núcleo no desalojable:
• Los procesos que se ejecutan en modo núcleo no pueden ser
desalojados.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
5
Industria y comunicaciones en Tiempo-Real
• Una llamada al sistema podría tardar demasiado tiempo para poder
admitirlo en procesamiento de tiempo real.
4-
Deshabilitación de interrupciones:
• Muy cercano al anterior está el problema de la sincronización.
• Para proteger los datos que podrían ser accedidos asíncronamente,
algunos diseñadores optan por inhibir las interrupciones durante las
secciones críticas Þmás eficiente que los semáforos.
• Sin embargo, pone en peligro la posibilidad de responder a eventos
externos de forma adecuada.
5-
Memoria Virtual:
• En STR introduce un nivel de impredecibilidad intolerable.
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.
2.2 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
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
6
Industria y comunicaciones en Tiempo-Real


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
Vemos las soluciones de algunos sistemas operativos convencionales que
hemos visto anteriormente.
1. QNX:
• Cumple el estándar POSIX.1b.
• Arquitectura de microkernel Þel núcleo implementa sólo cuatro
servicios: planificación de procesos, comunicación entre procesos,
comunicación de red de bajo nivel y manejo de interrupciones.
• El resto de servicios se implementan como procesos de usuario.
2. VxWorks:
• RTOS patentado orientado hacia la aproximación host/target.
• Un host UNIX es usado para el desarrollo del software y para la
ejecución de las partes de la aplicación que no son de tiempo real.
• El núcleo de VxWorks (llamado wind) ejecuta las tareas de tiempo
real en la máquina target.
• Las máquinas se comunican utilizando TCP/IP.
• Proporciona algunas funciones POSIX.1b.
Direcciones de interés:
– QNX: http://www.qnx.com
– VxWorks: http://www.wrs.com/products/html/vxwks52.html
2.3. 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;
–
Tiempos diferentes para su ejecución en diferentes máquinas
virtuales;
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
7
Industria y comunicaciones en Tiempo-Real
–
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
2.4. 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 cumplen 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.
2.5. PROCESOS E HILOS (THREAD) 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".
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
8
Industria y comunicaciones en Tiempo-Real
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
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.

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 de registros de propósito general.

Contenido del contador de programa (PC)

El contenido de la palabra de estado del programa (PSW).
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
9
Industria y comunicaciones en Tiempo-Real

Recursos utilizados del sistema operativo.

Cada proceso puede crear nuevos 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.
Un hilo de ejecución o thread , en sistemas operativos, es una característica
que permite a una aplicación realizar varias tareas concurrentemente. Los
distintos hilos de ejecución comparten una serie de recursos tales como el
espacio de memoria, los archivos abiertos, situación de autenticación, etc. Esta
técnica permite simplificar el diseño de una aplicación que debe llevar a cabo
distintas funciones simultáneamente.
Los hilos de ejecución que comparten los mismos recursos, sumados a estos
recursos, son en conjunto conocidos como un proceso. El hecho de que los
hilos de ejecución de un mismo proceso compartan los recursos hace que
cualquiera de estos hilos pueda modificar éstos. Cuando un hilo modifica un
dato en la memoria, los otros hilos acceden e ese dato modificado
inmediatamente a en la siguiente figura podemos observar un ejemplo de un
hilo de ejecución.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
10
Industria y comunicaciones en Tiempo-Real
Fig.1: Hilos (threads).
Lo que es propio de cada hilo es el contador de programa, la pila de
ejecución y el estado de la CPU (incluyendo el valor de los registros).
El proceso sigue en ejecución mientras al menos uno de sus hilos de
ejecución siga activo. Cuando el proceso es terminado, todos sus hilos de
ejecución también lo son. Asimismo en el momento en el que todos los hilos
de ejecución finalizan, el proceso no existe más y todos sus recursos son
liberados.
Algunos lenguajes de programación tienen características de diseño
expresamente creadas para permitir a los programadores lidiar con hilos de
ejecución (como Java). Otros (la mayoría) desconocen la existencia de hilos de
ejecución y éstos deben ser creados mediante llamadas de biblioteca
especiales que dependen del sistema operativo en el que estos lenguajes
están siendo utilizados.
Un ejemplo de la utilización de hilos es tener un hilo atento a la interfaz
gráfica (iconos, botones, ventanas), mientras otro hilo hace una larga
operación internamente. De esta manera el programa responde de manera más
ágil a la interacción con el usuario. También pueden ser utilizados por una
aplicación servidora para dar servicio a múltiples clientes de procesos.
2.6. PROCESOS E HILOS
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
11
Industria y comunicaciones en Tiempo-Real
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
hilos; 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.
2.7 DIFERENCIA ENTRE PROCESOS E HILOS
Los hilos se distinguen de los tradicionales procesos en que los procesos son
generalmente independientes, llevan bastante información de estados, e
interactúan sólo a través de mecanismos de comunicación dados por el
sistema. Por otra parte, muchos hilos generalmente comparten otros recursos
directamente. En muchos de los sistemas operativos que proveen facilidades
para los hilos, es más rápido cambiar de un hilo a otro dentro del mismo
proceso, que cambiar de un proceso a otro. Este fenómeno se debe a que los
hilos comparten datos y espacios de direcciones, mientras que los procesos al
ser independientes no lo hacen. Al cambiar de un proceso a otro el sistema
operativo (mediante el dispatcher) genera lo que se conoce como overhead,
que es tiempo desperdiciado por el procesador para realizar un cambio de
modo (mode switch), en este caso pasar del estado de Running al estado de
Waiting o Bloqueado y colocar el nuevo proceso en Running. En los hilos
como pertenecen a un mismo proceso al realizar un cambio de hilo este
overhead es casi despreciable.
Sistemas operativos como Windows NT, OS/2 y Linux (2.5 o superiores) han
dicho tener hilos 'baratos', y procesos 'costosos' mientras que en otros
sistemas no hay una gran diferencia.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
12
Industria y comunicaciones en Tiempo-Real
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.
2.8. VENTAJAS DE LOS HILOS
Si bien los hilos son generados a partir de la creación de un proceso,
podemos decir que un proceso es un hilo de ejecución, conocido como
Monohilo. Pero las ventajas de los hilos se dan cuando hablamos de
Multihilos, que es cuando un proceso tiene múltiples hilos de ejecución los
cuales realizan actividades distintas, que pueden o no ser cooperativas entre
sí. Los beneficios de los hilos se derivan de las implicaciones de rendimiento.
Se tarda mucho menos tiempo en crear un hilo nuevo en un proceso existente
que en crear un proceso. Algunas investigaciones llevan al resultado que esto
es así en un factor de 10.
Se tarda mucho menos en terminar un hilo que un proceso, ya que cuando se
elimina un proceso se debe eliminar el BCP del mismo, mientras que un hilo
se elimina su contexto y pila.
Se tarda mucho menos tiempo en cambiar entre dos hilos de un mismo
proceso
Los hilos aumentan la eficiencia de la comunicación entre programas en
ejecución. En la mayoría de los sistemas en la comunicación entre procesos
debe intervenir el núcleo para ofrecer protección de los recursos y realizar la
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
13
Industria y comunicaciones en Tiempo-Real
comunicación misma. En cambio, entre hilos pueden comunicarse entre sí sin
la invocación al núcleo. Por lo tanto, si hay una aplicación que debe
implementarse como un conjunto de unidades de ejecución relacionadas, es
más eficiente hacerlo con una colección de hilos que con una colección de
procesos separados.
Como resumen podemos decir que:

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.
2.9. 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.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
14
Industria y comunicaciones en Tiempo-Real
 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.

El estado del hilo 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).
Fig.2: Estados delos hilos.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
15
Industria y comunicaciones en Tiempo-Real
2.10. PRIORIDADES DE HILOS (THREADS) EN RTSJ
En un ambiente de tiempo real, las prioridades de los threads son de extrema
importancia. Ningún sistema puede garantizar que todas las tareas vayan a
completarse en tiempo. Sin embargo, un sistema de tiempo real puede
garantizar que si algunas de las tareas van a incumplir sus metas de tiempo,
entonces las tareas de menor prioridad serán las primeras en ser sacrificadas.
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 requiere un cumplimiento
estricto de las mismas. Sin embargo, como ya se mencionó, RTSJ depende de
un sistema operativo en tiempo real para soportar múltiples prioridades.
El problema de la inversión de prioridades puede afectar negativamente a las
prioridades. De esta manera, RTJS requiere la herencia de prioridades en su
gestión. La herencia de prioridad evita la inversión de prioridades, aumentando
la prioridad del thread que está bloqueando un recurso para igual la prioridad
del thread de mayor prioridad que está esperando el recurso.
Esto
evita
que
un
thread
de
prioridad
alta
se
queda
esperando
indefinidamente a un thread de menor prioridad que tiene bloqueado el
recurso, pero que no puede liberar porque no obtiene los ciclos de CPU
necesarios para finalizar su tarea.
Además, RTJS está diseñado para permitir que actividades de tiempo real y de
no tiempo real coexistan en la misma aplicación Java. El grado de garantías
temporales brindadas a una actividad dependen del tipo de thread en la cual
se ejecuta la actividad: java.lang.Thread o javax.realtime.RealtimeThread.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
16
Industria y comunicaciones en Tiempo-Real
•
Los
threads
comunes
java.lang.Thread
(JLT)
son
soportados
para
actividades no de tiempo real. Estos threads JTL pueden usar 10 niveles
de prioridad, pero no se brindan garantías de su ejecución en el
tiempo.
•
Los threads javax.realtime.RealtimeThread (RTT) toman ventaja de la
gestión de threads con prioridad de RTJS, y se administración de una
forma ejecutar-al-bloque, en lugar de por porciones de tiempo. Es decir,
el administrador de threads sólo va a realizar un thread switch cuando
un RTT de mayor prioridad esté listo para ejecutarse.
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
2.11. TIPOS DE MEMORIA Y SU USO EN LA FUNCIÓN RTSJ
RTSJ brinda varias formas de reservar memoria para objetos, dependiendo
de la naturaleza de la tarea realizando la reserva. Los objetos pueden
asignarse a un área de memoria específica, y las diferentes áreas tienen
diferentes características de GC y límites de reserva.
•
Heap estándard. Como cualquier máquina virtual, RTJS mantiene un
heap con garbage collector, el cual puede ser usado por los threads
estándard o de tiempo real. Los NHRT no pueden usar el heap
estándard para poder garantizar predecibilidad.
•
Memoria inmortal. La memoria inmortal es un área de memoria que no
tiene un gargabe collector. Una vez que el objeto se asigna a la
memoria inmortal, la memoria usada por este objeto nunca va a ser
liberada (en principio). El uso principal de la memoria inmortal es que
las
actividades
reservando
pueden
estáticamente
evitar
la
reservas
memoria
que
de
memorias
necesitan
dinámicas,
antes
de
la
ejecución, y gestionándola ellas mismas. Gestionar la memoria inmortal
requiere mucho más cuidado que administrar la memoria del heap
estándard.
•
Memoria acotada. RTSJ brinda un tercer mecanismo de reserva llamada
memoria acotada, que sólo está disponible para threads de tiempo real
(RTT y NHRT). Estas áreas de memoria están pensadas para objetos
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
17
Industria y comunicaciones en Tiempo-Real
con un tiempo de vida conocido, como ser objetos temporales creados
durante el procesamiento de una tarea. Al igual que la memoria
inmortal, la memoria acotada no tiene un garbage collector, pero la
diferencia es que el área completa de memoria puede reclamarse al
finalizar su uso, como ser al fin de la tarea. Estas áreas de memoria
tienen un límite máximo asignado al crearse, de forma de poder
controlar su uso y crecimiento.
2.12. LAS FUENTES DE INCERTIDUMBRE EN LA APLICACIÓN JAVA
Hay varios factores que llevan a la impredecibilidad de la ejecución de las
aplicaciones en el tiempo, y por lo tanto pueden causar que una aplicación
Java estándard no cumpla con las metas de tiempo. Las causas más
comunes:
•
Gestión del sistema operativo. En la tecnología Java, los threads son
creados por la JVM pero, en última instancia, son gestionados por el
sistema
operativo.
Para
que
una
JVM
pueda
garantizar
latencias
temporales, es decir, la demora en el tiempo en reaccionar ante una
acción, el sistema operativo tiene que brindar garantizas sobre la
latencia de su gestión de threads.
•
Inversión de prioridades. Un riesgo en una aplicación con threads es la
inversión de prioridades. Si un thread de menor prioridad comparte un
recurso con otro de mayor prioridad, y si el recurso está sincronizado
por un monitor, el thread de menor prioridad podría tener bloqueado el
recurso al momento que el thread de mayor prioridad lo necesita. En
este caso, el thread de mayor prioridad no puede proceder hasta que
el thread de menor prioridad termina su trabajo: y esto puede causar
que el thread de mayor prioridad no cumpla con su meta de tiempo.
El efecto de la inversión de prioridad es que se "baja" la prioridad del
thread de mayor prioridad a aquel de menor prioridad.
•
Carga de clases, inicialización y compilación. La especificación del
lenguaje Java requiere que las clases sean inicializadas de manera
perezosa: cuando una aplicación las utiliza por primera vez. Estas
instanciaciones pueden ejecutar código de usuario, creando así latencias
variables la primera vez que se usa la clase. Además, la especificación
permite que las clases se carguen de manera perezosa también. Como
la carga de clases pueden requerir accesos a disco o a través de una
red para encontrar la definición de la clase, referenciar a una clase sin
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
18
Industria y comunicaciones en Tiempo-Real
referencia
previa
puede
ocasionar
una
demora
inesperada
(y
potencialmente enorme). Por último, la JVM puede decidir cuando, si lo
hace,
traducir
Usualmente
se
el
código
compila
bytecode
un
método
de
la
sólo
clase
a
cuando
código
se
nativo.
ejecuta
tan
frecuentemente que justifica el costo de la compilación.
•
Garbage collector. La principal fuente de impredeciblidad en Java es el
Garbage Collector (GC). Los algoritmos de GC que usan las JVM
estándard involucran, de una manera u otra, detener-el-mundo-y-limpiar:
se suspenden todos los threads para que el GC puede ejecutarse sin
interferencias. Las aplicaciones con requerimientos estrictos de tiempo
no pueden tolerar estas pausas causadas por el GC. A pesar de todo el
trabajo que se viene realizando para reducir estas pausas, incluso un
GC de baja-pausa no es suficiente para garantizar la predecibilidad de
la ejecución.
•
La aplicación. Otra importante fuente de impredecibilidad es la misma
aplicación, incluyendo a todas las librerías que utiliza. La mayoría de las
aplicaciones consisten de diversas actividades que compiten de manera
igual por los recursos del CPU. Las aplicaciones Java en general no
utilizan threads con prioridad, en particular porque la JVM ofrece muy
pocas garantías acerca de estas prioridades. Así, completar una tarea
puede tardar más de lo esperado, lo que provoca que otras tareas
tengan que esperar para recursos del CPU.
•
Otras actividades en el sistema. Pueden existir otras actividades de alta
prioridad en el sistema, como ser interrupciones de hardware, otras
aplicaciones de tiempo real, y demás. Estas otras actividades pueden
interferir con la aplicación, y así afectar el determinismo.
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.
2.13. 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
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
19
Industria y comunicaciones en Tiempo-Real
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.
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.
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
enfoques específicos 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.

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 aumentada 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.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
20
Industria y comunicaciones en Tiempo-Real
 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.

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,
RTS
2.0,
http://jcp.org/en/jsr/detail?id=1.
 La
realización
de
la
versión
2.0
de
Sun,
Java
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 de 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.
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
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
21
Industria y comunicaciones en Tiempo-Real
Fig.3: GC BASADO EN EL TRABAJO.
Fig.4: GC BASADOS EN EL TIEMPO.
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
22
Industria y comunicaciones en Tiempo-Real
Fig.5: GC HENRIKSSON.
3. CONCLUSIONES
Ahora podemos entender cómo funcionan los OS en Tiempo-Real, las ventajas
y desventajas que proporcionan. En particular Java como OS en tiempo real.
4. BIBLIOGRAFÍA Y/O REFERENCIAS
[1] Elección de los OS en Tiempo Real. prof. Manuel Castro, de la Universidad
UNED de Madrid. Algunas adiciones fueron hechas por el prof. Anton Petrov departamento ЕCIТ en PU Plovdiv.
[2] An introduction to Real-Time Java Technology: Part 1, The Real-Time
specification for Java. http://www.oracle.com/technetwork/java/index.html
[3] An introduction to Real-Time Java Technology: Part 2, Garbage collection
and Java RTS
5. ENLACES DE INTERÉS
•
http://java.sun.com/javase/technologies/realtime/index.jsp
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
23
Industria y comunicaciones en Tiempo-Real
•
http://jcp.org/aboutJava/communityprocess/mrel/jsr001/index2.html
•
http://www.timesys.com/java/
ELECCIÓN DE LOS OS EN TIEMPO-REAL. JAVA COMO UN OS EN TIEMPO-REAL
24