Sistemas Embebidos: latencia fija

Photo by Skitterphoto on Pexels.com

Introducción

En sistemas embebidos, es común encontrar situaciones en que es mejor tener una latencia precisa que pequeña. En otras palabras, es mejor un sistema lento pero que responde en un tiempo conocido, que un sistema rápido cuyo tiempo de respuesta es desconocido.

Ejemplo

Supongamos que queremos construir un sistema esclavo que ejecute los comandos enviados por un dispositivo maestro. Para implementar un sistema de latencias predeterminadas propongo utilizar un par de hilos de ejecución (threads) y un par de filas (queues) con capacidad de un elemento.

El primer hilo de ejecución se encargará de manejar la comunicación entre nuestro sistema y el dispositivo maestro. El segundo hilo se encargará de ejecutar los comandos solicitados por el dispositivo maestro.

Nuestro sistema tendría entonces dos filas: una donde el hilo de comunicaciones coloca las solicitudes de ejecución de los comandos; y la otra donde el hilo de ejecución de comandos coloca las respuestas de los comandos.

Análisis

Supongamos que nuestra interfaz para ejecutar un comando se llama ejecutar_comando, y que pretendemos garantizar una latencia de respuesta fija a la que simbólicamente me refiero como LATENCIA_FIJA. Su implementación sigue el algoritmo descrito por el pseudo-código debajo de este párrafo.


ejecutar_comando(comando, parámetros, respuesta):
    respuesta = NADA
    si hilo_de_ejecución_esta_ocupado():
        retornar OCUPADO
    poner_comando_en_fila_de_ejecución(
        comando, parámetros)
    esperar(LATENCIA_FIJA)
    si fila_de_respuestas_esta_llena():
        respuesta = sacar_respuesta_de_fila()
        retornar ÉXITO
    en otro caso:
        retornar SIN_RESPUESTA

Un segundo beneficio

Con este esquema de trabajo ganamos un segundo beneficio, además de la latencia predeterminada. Al tener un hilo de ejecución para las comunicaciones y otro para la ejecución de comandos, en caso de que haya un problema será más sencillo distinguir si: es causado por un comando que no funciona, o porque las comunicaciones no están funcionando apropiadamente.

¿En qué caso se usa esto?

Y a todo esto ¿para qué querríamos la latencia fija en la práctica? La respuesta radica en la sensibilidad del dispositivo maestro a la latencia de los sistemas que controla. Por ejemplo, si el dispositivo maestro es un sistema de latencia indeterminada (quizá porque su implementación usa tecnología vieja, o utiliza un sistema operativo que planea sus tareas de forma no determinística), entonces es importante poder garantizarle una latencia fija a la cuál podrá obtener respuesta de los sistemas que controla.