MicroKernel
Comunicación entre procesos 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.
Comunicación entre procesos 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)
Comunicación entre procesos
Comunicación entre procesos IPC via proxies Comunicación asíncrona entre procesos (notificación de eventos). No bloqueante Los mensajes también pueden mandarse por la red
Comunicación entre procesos 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.
Comunicación de la red QNX ofrece transparencia en la comunicación con procesos remotos. 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. 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.
Comunicación de la red 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.
Comunicación de la red 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.
Comunicación de la red 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.
Scheduling de procesos El scheduler del MicroKernel toma decisiones de planificación cuando un proceso se bloquea, el quantum de un proceso expira o un proceso se desaloja. Selecciona el proceso con prioridad más alta que se encuentra en la cola de procesos preparados para ejecutarse. En caso de empate, QNX proporciona tres métodos de planificación: FIFO, Round-robin y Adaptativa.
Cola de prioridades Scheduling de procesos
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. Scheduling de procesos
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. Este tiempo se conoce como latencia: 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.
Gestión de Interrupciones Latencia de interrupciones según procesador 3.3 microsec Pentium de 166 MHz 4.4 microsec Pentium de 100 MHz 5.6 microsec 486DX4 de 100 MHz 22.5 microsec 386EX 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.
Gestión de Interrupciones – Al finalizar la atención a una interrupción, el Gestor puede mandar un proxy a otro proceso para que se active Process A is running. Interrupt IRQx causes interrupt handler Intx to run, which is preempted by IRQy and its handler Inty. Inty triggers a proxy causing Process B to run; Intx triggers a proxy causing Process C to run.
Gestión de Interrupciones 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. Latencia de scheduling 4.7 microsec Pentium de 166 MHz 6.7 microsec Pentium de 100 MHz 11.1 microsec 486DX4 de 100 MHz 74.2 microsec 386EX de 33 MHz
http://support.qnx.com/support/docs/qnx4/sysarch/proc.htm
Documentación de CASO
| Página siguiente |