CONCEPTES AVANATS DE SISTEMES OPERATIUS Departament dArquitectura de

  • Slides: 27
Download presentation
CONCEPTES AVANÇATS DE SISTEMES OPERATIUS Departament d’Arquitectura de Computadors QNX (Un ejemplo de SOTR)

CONCEPTES AVANÇATS DE SISTEMES OPERATIUS Departament d’Arquitectura de Computadors QNX (Un ejemplo de SOTR) (Seminaris de CASO) Autors Javier Sebastián Carretero Casado o Ricard Pascual Pijoan o Antonio Juan Prieto Jiménez o

La filosofía de QNX Las aplicaciones de tiempo real dependen del sistema operativo para

La filosofía de QNX Las aplicaciones de tiempo real dependen del sistema operativo para manipular eventos múltiples dentro de restricciones fijas de tiempo. o QNX es ideal para las aplicaciones de tiempo real. Proporciona multitarea, planificación por prioridades con desalojo, y rápido cambio de contexto. o Flexible, robusto, escalable y fácil de personalizar. o – Pueden añadirse funcionalidades (p. e: drivers) sin adquirir una nueva versión del producto. 2

La filosofía de QNX Su API cumple el estándar POSIX. o Los SO de

La filosofía de QNX Su API cumple el estándar POSIX. o Los SO de tiempo real se caracterizan por una ausencia de estándars. QNX propone : o -Estándar POSIX 1003. 1, que define la API para la gestión de procesos, dispositivos, y sistemas de ficheros y IPC básica. (Funcionalidades básicas). -Extensiones para tiempo real : semáforos, planificación prioritaria de procesos, control del reloj mayor, primitivas IPC mejoradas. -Threads … 3

La filosofía de QNX o QNX consigue su eficiencia, modularidad y simplicidad gracias a

La filosofía de QNX o QNX consigue su eficiencia, modularidad y simplicidad gracias a 2 principios: - Una arquitectura microkernel - Comunicación de procesos basada en paso de mensajes. o La arquitectura del Microkernel de QNX: – Microkernel muy pequeño que, básicamente, se dedica al intercambio de mensajes (asignación de la ruta) y a la planificación de procesos (se invoca cuando un proceso cambia de estado, por una interrupción o por un mensaje) 4

La filosofía de QNX 5

La filosofía de QNX 5

La filosofía de QNX o Los servicios, excepto los del microkernel, los ofrecen procesos:

La filosofía de QNX o Los servicios, excepto los del microkernel, los ofrecen procesos: – – Administrador de procesos (Proc) Administrador del sistema de archivos (Fsys) Administrador de dispositivos (Dev) Administrador de red (Net) 6

La filosofía de QNX o Primer S. O. Comercial de su tipo en utilizar

La filosofía de QNX o Primer S. O. Comercial de su tipo en utilizar intercambio de mensajes (IPC). – QNX no presta atención al contenido del mensaje. – IPC también proporciona mecanismos de sincronización entre varios procesos. o QNX como una red: – Permite el acceso por parte de los procesos a todos los recursos de la red de manera transparente. – Los usuarios pueden acceder a archivos en cualquier parte en la red, aprovechar dispositivos y periféricos, y ejecutar aplicaciones en cualquier máquina en la red (siempre que tengan la autorización apropiada). 7

La filosofía de QNX o Soporte para SMP (Symmetric Multi-Processing) – Soporta hasta 8

La filosofía de QNX o Soporte para SMP (Symmetric Multi-Processing) – Soporta hasta 8 procesadores Pentium. – Para añadir esta funcionalidad tan solo hay que modificar el microkernel, de manera que los procesos que implementan las demás funcionalidades del sistema se beneficien automáticamente. – Mejora aún más si los procesos son Multi. Threads. – Al modificar solo el microkernel, el añadir esta funcionalidad hace que el código tan solo aumente unos pocos kilobytes. 8

Micro. Kernel o El Micro. Kernel es responsable de lo siguiente: - IPC -

Micro. Kernel o El Micro. Kernel es responsable de lo siguiente: - IPC - gestión de mensajes proxies y señales. - La comunicación de la red a bajo nivel - gestión de mensajes destinados a procesos en otros nodos - Scheduling de procesos - orden de ejecución de procesos. - Gestión de interrupciones del primer nivel - todas las interrupciones hardware y fallos primero deben pasar por el Microkernel y luego se pasan al driver o administrador de sistema. 9

Micro. Kernel 10

Micro. Kernel 10

Comunicación entre procesos o El microkernel de QNX soporta 3 tipos de IPC: –

Comunicación entre procesos o El microkernel de QNX soporta 3 tipos de IPC: – Mensajes: • La forma fundamental de IPC en QNX. Requiere confirmación del receptor y, posiblemente, contestación. – Proxies: • Una forma especial de mensaje. Preparado para notificar eventos donde el proceso que lo envía no necesita actuar recíprocamente con el destinatario. – Señales (Signals): • Una forma tradicional de IPC. Se utiliza para comunicar procesos asíncronamente. 11

Comunicación entre procesos o IPC vía mensajes – Paquete de bytes que se transmite

Comunicación entre procesos o IPC vía mensajes – Paquete de bytes que se transmite de manera síncrona entre dos procesos. – Utiliza las primitiva Send(), Receive() y Reply() (para contestar al proceso que ha mandando el mensaje) • Pueden usarse tanto localmente como por la red • Son bloqueantes – Adicionalmente QNX ofrece facilidades como: • Recepción condicional de mensajes • Leer/escribir partes de mensajes • Mandar mensajes por partes (optimiza E/S) 12

Comunicación entre procesos 13

Comunicación entre procesos 13

Comunicación entre procesos o IPC via proxies – Comunicación asíncrona entre procesos (notificación de

Comunicación entre procesos o IPC via proxies – Comunicación asíncrona entre procesos (notificación de eventos). No bloqueante – Los mensajes también pueden mandarse por la red 14

Comunicación entre procesos o IPC vía señales (signals) – Sistema típico para la comunicación

Comunicación entre procesos o IPC vía señales (signals) – Sistema típico para la comunicación asíncrona – Soporta un gran conjunto de signals POSIX, algunos tradicionales de UNIX y algunos específicos de QNX – Al recibir un signal, el proceso puede: • No hacer nada. Se ejecuta la acción por defecto (lo mata) • Ignorarlo (excepto SIGCONT, SIGKILL, y SIGSTOP) • Capturarlo y actuar en consecuencia – Si llegan varios signals en un momento dado, el proceso no puede asumir ningún orden de llegada. – Permite bloquear signals. 15

Comunicación de la red QNX ofrece transparencia en la comunicación con procesos remotos. o

Comunicación de la red QNX ofrece transparencia en la comunicación con procesos remotos. o Para lograrlo utiliza circuitos virtuales (VC), qué son los caminos que el Administrador de Red proporciona para transmitir mensajes, proxies y señales por la red. o Cuando un proceso quiere comunicarse con un proceso remoto este hace una llamada a sistema (qnx_vc_attach()) que crea un circuito virtual y dos procesos virtuales en cada extremo del circuito. o 16

Comunicación de la red o Ejemplo de comunicación en la red: Un proceso en

Comunicación de la red o Ejemplo de comunicación en la red: Un proceso en el nodo 20(PID 1) quiere enviar un mensaje a otro proceso en el nodo 40(PID 2) y crea un circuito virtual. El proceso PID 1 primero envía el mensaje a su proceso virtual, luego este envía el mensaje al segundo proceso virtual que finalmente retransmite el mensaje al proceso PID 2. 17

Comunicación de la red o Proxy virtual Un proxy virtual se crea mediante la

Comunicación de la red o Proxy virtual Un proxy virtual se crea mediante la llamada qnx_proxy_rem_attach() que recibe como parámetros el nodo remoto y un proxy local. Permite que cualquier proceso del nodo remoto pueda lanzar proxies al proceso que lo crea. 18

Comunicación de la red o Integridad de los circuitos virtuales El Administrador de Red

Comunicación de la red o Integridad de los circuitos virtuales El Administrador de Red controla cada cierto tiempo la integridad de los circuitos virtuales para evitar errores en la comunicación. Para conseguirlo realiza lo siguiente: - Actualiza el último acceso al circuito virtual. - En distintos intervalos de tiempo comprueba si el circuito está en uso, si no lo usa nadie comprueba enviando un mensaje al Administrador de Red del otro extremo si el circuito continua activo. - Sino recibe mensaje o recibe una notificación de error intenta restablecer la comunicación. - Sino lo consigue desbloquea todos los procesos bloqueados en el circuito virtual y les devuelve un código de error. 19

Scheduling de procesos El scheduler del Micro. Kernel toma decisiones de planificación cuando un

Scheduling de procesos El scheduler del Micro. Kernel toma decisiones de planificación cuando un proceso se bloquea, el quantum de un proceso expira o un proceso se desaloja. o Selecciona el proceso con prioridad más alta que se encuentra en la cola de procesos preparados para ejecutarse. o En caso de empate, QNX proporciona tres métodos de planificación: FIFO, Round-robin y Adaptativa. o 20

Scheduling de procesos Cola de prioridades 21

Scheduling de procesos Cola de prioridades 21

Scheduling de procesos o Planificación adaptativa Si un proceso consume su quantum (sin bloquearse),

Scheduling de procesos o Planificación adaptativa Si un proceso consume su quantum (sin bloquearse), su prioridad se reduce 1 unidad. Si continua siendo el proceso con mayor prioridad seguirá ejecutándose aunque no reducirá más su prioridad. El proceso vuelve a su prioridad original cuando se bloquea. 22

Gestión de Interrupciones En un RTSO es esencial minimizar el tiempo entre que se

Gestión de Interrupciones En un RTSO es esencial minimizar el tiempo entre que se sucede un evento y que lo recibe el programa responsable de actuar. o Este tiempo se conoce como latencia: o – Es el tiempo entre que se produce la interrupción hasta que se ejecuta la primera instrucción del Gestor de interrupciones software. – QNX habilita las interrupciones el máximo de tiempo posible. Aunque en algunas regiones críticas las inhabilita. De todas maneras, en QNX la latencia es muy pequeña. 23

Gestión de Interrupciones o Latencia de interrupciones según procesador 3. 3 microsec 4. 4

Gestión de Interrupciones o Latencia de interrupciones según procesador 3. 3 microsec 4. 4 microsec 5. 6 microsec 22. 5 microsec o Pentium de 166 MHz Pentium de 100 MHz 486 DX 4 de 100 MHz 386 EX de 33 MHz QNX soporta interrupciones de distinta prioridad – Mientras se atiende una interrupción, si llega otra más prioritaria pasa a atender a la nueva. 24

Gestión de Interrupciones Process A is running. Interrupt IRQx causes interrupt handler Intx to

Gestión de Interrupciones Process A is running. Interrupt IRQx causes interrupt handler Intx to run, which is preempted by IRQy and its handler Inty triggers a proxy causing Process B to run; Intx triggers a proxy causing Process C to run. - Al finalizar la atención a una interrupción, el Gestor puede mandar un proxy a otro proceso para que se active 25

Gestión de Interrupciones o La gestión de interrupciones también afecta a la planificación de

Gestión de Interrupciones o La gestión de interrupciones también afecta a la planificación de procesos. – Al producirse una interrupción tiene que cargarse el proceso del driver (cambio de contexto). Es costoso, pero en QNX es bastante rápido. o Latencia de scheduling 4. 7 microsec 6. 7 microsec 11. 1 microsec 74. 2 microsec Pentium de 166 MHz Pentium de 100 MHz 486 DX 4 de 100 MHz 386 EX de 33 MHz 26

Bibliografia o http: //support. qnx. com/support/docs/qnx 4/sysarc h/proc. htm o Documentación de CASO 27

Bibliografia o http: //support. qnx. com/support/docs/qnx 4/sysarc h/proc. htm o Documentación de CASO 27