SOM30

En las últimas tres entradas veíamos como los diferentes módulos estarán ofreciendo al kérnel del Sistema Operativo los tres entornos para que las Soluciones Informáticas funcionen en el Sistema Informático. Cada uno de estos entornos están destinados a trabajar con procesos, programas y aplicaciones desarrolladas, respectivamente, a bajo nivel, medio nivel y alto nivel, con diferentes características ventajosas y sus correspondientes inconvenientes. Aunque los problemas inherentemente desaparecen cuando las Soluciones Informáticas se presentan en el Sistema Informático de forma independiente, al aparecer varias trabajando concurrentemente, aparecen grandes problemas que afectan de pleno a las políticas de estanqueidad y conectividad.

Viendo este panorama, toca abordar el tema "¿qué pasará cuando queremos usar dos Soluciones Informáticas a la vez?". La respuesta a esa pregunta es el concepto de multitarea.

Partiendo de la base de un Sistema Informático, éste siempre será monotarea. De todas formas, bajo un Sistema se podrán juntar varios Sistemas Informáticos reales mapeados en el Espacio de Direcciones a modo de controladores trabajando en paralelo, permitiendo una multitarea real. Este tipo conlleva un mayor coste debido a que se presentarán recursos reales replicados y, posiblemente, inutilizados. De todas formas, es posible obtener una multitarea virtual en cualquier Sistema garantizando las habituales políticas.

Como decía al comienzo, sobre nuestro Sistema Operativo van a aparecer tres tipos de entornos donde funcionarán los procesos, programas y aplicaciones. Teniendo en cuenta que las aplicaciones se tratarán como programas generados por el SAM, y los Sistemas Informáticos generados por el ViSi para la ejecución de procesos también son, en esencia, programas... todo queda reducido a controlar la concurrencia entre programas. Debido a que los propios módulos son programas, resulta un poco complicado teóricamente controlarlos. La salvedad está en el propio kérnel, que será el encargado de controlar la ejecución de todos los demás programas que se ejecuten sobre el Sistema Informático.

El mecanismo básico será dar una serie de ciclos a los programas en función de su prioridad. La prioridad se calculará en base a ciertos parámetros de la propia solución informática, aunque otros los determinará el propio kérnel, por ejemplo, teniendo en cuenta su procedencia o el estado general del Sistema. En caso de que la Solución Informática retorne el control al Sistema Operativo, se dará por finalizado su tiempo de ejecución en ese cuanto. Los programas podrán comunicarse con el Sistema Operativo a través de las llamadas al LiSi para solicitar cambios en la prioridad a través de desafíos que garanticen su veracidad. Igualmente, se podrán dormir o suspender en caso de que el Sistema Operativo, el propio proceso, programa o aplicación lo desee, o, incluso, una tercera Solución Informática lo indique supervisándolo siempre el Sistema Operativo.

En el caso general de los programas, es posible controlar el flujo de ejecución de los programas ya que el código máquina a ejecutar está formado por el juego de instrucciones propio de la arquitectura que habíamos seleccionado, y las instrucciones de salto pueden ser predictibles y, por lo tanto, saber hacia donde se dirigirá la ejecución del programa. Como los programas (salvo los módulos) siempre utilizan la LiSi para realizar los saltos, y debido a que el LiSi es parte del Sistema Operativo, siempre se garantiza que el propio Sistema Operativo va a recuperar el control del Sistema pasado el número de ciclos determinado para cada programas; igualmente, se puede calcular el número de ciclos que pasarán entre cada llamada a la función de salto del LiSi, y por lo tanto, permitir o no la ejecución de ese programas.

En el caso particular de los procesos, ejecutados sobre un Sistema Informático generalmente virtualizado (aunque como expliqué al comienzo podría tratarse de una máquina real mapeada en el Espacio de Direcciones, en cuyo caso no habría que preocuparse por la concurrencia), es más sencillo teóricamente de controlar debido a la naturaleza virtualizada del Sistema Informático que lo hace funcionar. De todas formas, los ciclos, al ser virtualizados y por lo tanto consumir más recursos (sobre todo tiempo, ya que un ciclo virtualizado corresponde con varios ciclos reales), suelen ser más reducidos que en el caso de los programas, que un ciclo corresponde a un ciclo real. De todas formas, los procesos sobre un SIM virtualizado tienen las máximas libertades en cuanto a utilización de los recursos (generalmente virtualizados) del Sistema Informático en donde se ejecute.

Por último, con las aplicaciones el tema de la concurrencia se ve altamente facilitado ya son ejecutados por el módulo SAM, el cual pertenece al Sistema Operativo. De todas formas, los programas generados a partir de las aplicaciones por el SAM no van a tener directamente restricciones en cuanto a número de ciclos que podrán usar el Sistema Informático, aunque sí estarán obligados a ceder la ejecución en cuanto otro programa o proceso lo precise de forma fundamentada. En ese caso, el Sistema Operativo ordenará al SAM pausar la ejecución de esa aplicación y ceder el control al kérnel para continuar la ejecución correspondiente.

Con este mecanismo será posible ejecutar de forma concurrente varias Solución Informática en un mismo Sistema Informático. Ahora toca irremediablemente conocer más a fondo las características propias de cada uno de los módulos del Sistema Operativo. Durante las próximas entradas, perfilaremos los Controles y Administradores que tendrán el Sistema Operativo y el Sistema de Aplicaciones respectivamente, y cómo convivirán esos recursos en el Sistema Informático.