Sistemas operativos modernos

Los sucesos a los que un sistema en tiempo real podría tener que responder pueden clasi­ ficarse como periódicos (que se presentan en intervalos regulares) o aperiódicos (cuya ocu­ rrencia es impredecible). Un sistema podría tener que responder a múltiples series de sucesos periódicos. Dependiendo del tiempo que tome procesar cada suceso, podría no ser siquiera po­ sible manejarlos todos. Por ejemplo, si hay m sucesos periódicos y el suceso i ocurre con un periodo y su manejo requiere Q segundos de tiempo de CPU, la carga sólo podrá manejar­ se si m 1= 1 “ i Si un sistema en tiempo real satisface este criterio, se dice que es calendarizable. Por ejemplo, consideremos un sistema en tiempo real no estricto con tres sucesos periódi­ cos, con periodos de 100, 200 y 500 ms, respectivamente. Si el manejo de estos sucesos requie­ re 50, 30 y 100 ms de tiempo de CPU, respectivamente, el sistema es calendarizable porque 0.5 + 0.15 + 0.2 < 1. Si se añade un cuarto suceso con un periodo de 1 s, el sistema seguirá sien­ do calendarizable, en tanto este suceso no necesite más de 150 ms de tiempo de CPU para su manejo. En este cálculo está implícita la suposición de que el gasto extra por conmutación de contexto es tan pequeño que puede ignorarse. Los algoritmos de calendarización para tiempo real pueden ser estáticos o dinámicos. Los primeros toman sus decisiones de calendarización antes de que el sistema comience a ejecutar­ se. Los segundos toman las decisiones en tiempo de ejecución. La calendarización estática só­ lo funciona si con anticipación se cuenta con información perfecta acerca del trabajo que debe efectuarse y de los plazos a cumplir. Los algoritmos de calendarización dinámica no tienen es­ tas restricciones. Aplazaremos nuestro estudio de algoritmos específicos hasta que veamos los sistemas multimedia en tiempo real en el capítulo 7. 2.5.5 Política en comparación con mecanismo Hasta ahora, hemos dado por hecho en forma tácita que todos los procesos del sistema pertene­ cen a usuarios distintos y, por lo tanto, están compitiendo por la CPU. Aunque muchas veces es­ to es cierto, hay ocasiones en que un proceso tiene muchos hijos ejecutándose bajo su control. Por ejemplo, un proceso de sistema de administración de bases de datos podría tener muchos hijos. Cada uno podría estar trabajando con una solicitud distinta, o podría estar desempeñando una función específica (análisis de solicitudes, acceso a disco, etcétera). Es muy posible que el proceso principal sepa exactamente cuáles de sus hijos son más importantes (o para cuáles es más crucial el tiempo), y cuáles lo son menos. Lamentablemente, ninguno de los calendarizadores que hemos visto aceptan información de los procesos de usuario relacionada con sus decisiones de calendarización. Por ello, el calendarizador casi nunca toma la decisión óptima. La solución a este problema es separar el mecanismo de calendarización de la política de calendarización. Esto significa que el algoritmo de calendarización tiene ciertos paráme­ tros que pueden especificar los procesos de usuario. Consideremos otra vez el ejemplo de una