Sistemas operativos modernos

Cuando el usuario emite un comando al procesador de texto, el calendarizador no tiene que tra­ bajar mucho para determinar qué proceso ejecutará: el procesador de texto es el único candidato. Segundo, con el paso de los años las computadoras se han vuelto tan rápidas que la CPU ya casi nunca es un recurso escaso. La mayoría de ios programas para computadoras persona­ les está limitada por la rapidez con que el usuario puede suministrar entradas (tecleando o ha­ ciendo clic), no por la rapidez con que la CPU puede procesarlas. Incluso las compilaciones, grandes devoradoras de ciclos de CPU en otros tiempos, tardan cuando más unos pocos segun­ dos en la actualidad. Aun si dos programas se están ejecutando a la vez, como un procesador de texto y una hoja de cálculo, no es muy importante cuál se ejecuta primero porque con toda seguridad el usuario está esperando que los dos terminen. Por consiguiente, ia calendarización no es tan importante en las PCs sencillas. (Claro que hay aplicaciones que casi se comen viva a la CPU: la generación de una hora de vídeo de alta definición podría requerir un procesa­ miento de imágenes de potencia industrial para cada uno de 108,000 cuadros en NTSC [90,000 en PAL], pero tales aplicaciones son la excepción más que la regla.) Si pasamos a las estaciones de trabajo y servidores de alta capacidad conectados a redes, la situación cambia. Aquí es común que varios procesos compitan por la CPU, así que ia ca­ lendarización vuelve a ser importante. Por ejemplo, cuando la CPU fiene que escoger entre eje­ cutar un proceso que actualiza la pantalla después de que un usuario ha cerrado una ventana y ejecutar un proceso que envía correo electrónico en cola, la diferencia en cuanto a respuesta percibida es considerable. Si el cierre de la ventana tarda 2 segundos mientras se está envian­ do el correo, es probable que el usuario pensará que el sistema está muy lento, mientras que si el correo se retrasa 2 segundos, el usuario de seguro ni se dará cuenta. En este caso, la calen­ darización de procesos cuenta mucho. Además de escoger el proceso que más conviene ejecutar, el calendarizador debe preocupar­ se por aprovechar con eficiencia la CPU porque la conmutación de procesos es costosa. Por prin­ cipio de cuentas, es necesario un cambio de modo de usuario a modo de kemel. Luego debe guardarse el estado del proceso actual, lo cual incluye almacenar sus registros en la tabla de procesos para que puedan volverse a cargar más adelante. En muchos sistemas, también debe guardarse el mapa de memoria (por ejemplo, bits de referencia a la memoria en la tabla de pági­ nas). Luego debe seleccionarse un nuevo proceso mediante la ejecución del algoritmo de calenda­ rización. Después, se deberá cargar la MMU con el mapa de memoria del nuevo proceso. Por último, debe ponerse en marcha el nuevo proceso. Además de todo lo anterior, la conmutación de procesos casi siempre anula la validez de todo el caché de memoria, que deberá cargarse dos ve­ ces en forma dinámica desde la memoria principal (al entrar en el kemel y al salir de él). En sín­ tesis, la ejecución de demasiadas conmutaciones de proceso por segundo puede consumir una canüdad apreciable de tiempo de CPU, así que debemos ser cautelosos. Comportamiento de los procesos Casi todos los procesos alternan ráfagas de cómputo con solicitudes de E/S (de disco), como se muestra en la figura 2-37. Por lo general, la CPU opera durante un tiempo sin parar, y luego se emite una llamada al sistema para leer de un archivo o escribir en uno. Cuando la llamada al sistema termina, la CPU vuelve a computar hasta que necesita o tiene que escribir más datos, y