Manejo del tiempo en un programa

Manejo del tiempo en un programa
El recurso tiempo es un recurso básico para cualquier ordenador. Algunos, de los problemas que resuelve
cada sistema operativo con este recurso son:





Cambiar el programa activo (TIME SLICE) en sistemas multitarea como Win95’98 UNIX etc.
Calcular la fecha del sistema – se utiliza de casi cualquier programa de Office, de todos los entornos de
programación, de todos los sistemas de manejo de archivos etc.
Realizar tareas periódicas, como por ejemplo guardar el fichero del un editor, comprobar el correo
electrónico, etc.
Arrancar tareas en un momento determinado (por ejemplo ejecutar un programa fuera del horario de
trabajo, cargar ficheros del Internet por la noche, manejar objetos a distancia etc.).
Tareas de tiempo real
Salvo en sistemas muy simples y dedicados a un solo problema se controla con reloj (timer). El reloj del
sistema es esencialmente un contador, que cuenta con una frecuencia fija, conocida por el sistema y que no
depende de la velocidad del procesador. En esta manera el reloj del sistema no depende de características,
como por ejemplo la carga del procesador, el tipo del problema que se resuelve, los dispositivos conectados
etc.
El procesador recibe periódicamente peticiones de interrupción (interrupt request, IRQ) del parte del
reloj. Normalmente el reloj sigue contando después de emitir la interrupción. El procesador recibe el IRQ y
cuando está dispuesto a recibir interrupciones (STI) procesa la interrupción. Esto significa que el procesador
procesa la interrupción siempre después de recibir el IRQ, pero en un momento no determinado. Por esta
razón es importante que el reloj sigue contando. Al leer los registros del reloj el programa puede determinar el
punto del tiempo con una gran precisión, normalmente en un margen no mayor de 10 micro segundos.
Al procesar la interrupción el sistema operativo ejecuta todas las tareas necesarias en este momento,
según su estado interno, como por ejemplo, cambiar el contador del reloj de tiempo real, cambiar el programa
corriendo en el momento por otra si es preciso, devolver error a los programas que han agotado el tiempo
máximo permitido para la operación, etc., etc.
Después la mayoría de los sistemas uní tarea (single tasking) dan el control del usuario utilizando
mecanismos dependientes del sistema. En DOS esta acción se realiza a través de la interrupción 1Ch. Al
recibir el control el usuario puede ejecutar parte de su código y dar el control al usuario que ha tenido el
control antes de encadenarse en 1Ch.
El momento de procesar el IRQ no solo no esta determinado, sino que también es asíncronico con las
tareas que se ejecutan, incluso con las tareas del propio sistema operativo (SO). Es decir la interrupción 1Ch
puede ejecutarse por ejemplo en un momento en que los datos de un fichero están parcialmente escritos en el
disco, entre dos comandos de manejo de un dispositivo etc.
Si el SO se llama en este momento, el SO no puede guardar los datos en un estado coherente y hay
peligro de desintegración del sistema si no se mantiene una disciplina rigurosa del parte del SO. La misma
disciplina es necesaria de parte de los programas del usuario si no hay protección de hardware. Por esta razón
dentro de una interrupción el SO puede llamarse solo cuidando unas reglas. La mejor táctica es no llamar
al sistema operativo dentro de interrupciones 1Ch, que supone una complejidad añadida al manejar el tiempo
real de programas de usuario con SO no diseñados para trabajo en tiempo real, como por ejemplo DOS o
Windows.
Como conclusión, no será correcto leer el fichero en la practica 1 al procesar la interrupción 1Ch, ya
que un fichero abierto es una propiedad del SO. Lo correcto seria hacer un contador en la interrupción 1Ch.
Fuera de esta interrupción se comprueba en un bucle el teclado y también el contador. Si sube por encima de
un valor determinado se lee el siguiente byte fuera de la interrupción 1Ch. También esta claro
que si el SO no es una SO de tiempo real (RTOS), los procesos que necesitan este tipo de programación
deberían ser bastante lentos, para garantizar estadísticamente el comportamiento del sistema como RTOS. En
general si utilizamos DOS no es fiable manejar procesos que cambian su estado con frecuencia mayores de
1Hz. Si utilizamos solo BIOS podemos manejar procesos con frecuencia entre 10 y 50Hz.