2.5 NIVELES OBJETIVOS Y CRITERIOS DE PLANIFICACION

2.5 Niveles, objetivos y criterios de planificación.

Uno de los módulos más importantes de un sistema operativo es la de administrar los procesos y tareas del sistema de cómputo. En esta sección se revisarán dos temas que componen o conciernen a este módulo: la planificación del procesador y los problemas de concurrencia. Planificación del procesador

La planificación del procesador se refiere a la manera o técnicas que se usan para decidir cuánto tiempo de ejecución y cuando se le asignan a cada proceso del sistema. Obviamente, si el sistema es monousuario y monotarea nohay mucho que decidir, pero en el resto de los sistemas esto es crucial para el buen funcionamiento del sistema. Niveles de planificación
En los sistemas de planificación generalmente se identifican tres niveles: el alto, em medio y el bajo. El nivel alto decide que trabajos (conjunto de procesos) son candidatos a convertirse en procesos compitiendo por los recursos del sistema; el nivel intermedio decide que procesos se suspenden o reanudan para lograr ciertas metas de rendimiento mientras que el planificador de bajo nivel es el que decide que proceso, de los que ya están listos (y que en algún momento paso por los otros dos planificadores) es al que le toca ahora estar ejecutándose en la unidad central de procesamiento. En este trabajo se revisaran principalmente los planificadores de bajo nivel porque son los que finalmente eligen al proceso en ejecución. Objetivos de la planificación
Una estrategia de planificación debe buscar que los procesos obtengan sus turnos de ejecución apropiadamente, conjuntamente con un buen rendimiento y minimización de la sobrecarga (overhead) del planificador mismo. En general, se buscan cinco objetivos principales:

·         Justicia o Imparcialidad: Todos los procesos son tratados de la misma forma, y en algún momento obtienen su turno de ejecución o intervalos de tiempo de ejecución hasta su terminación exitosa.

·         Maximizar la Producción: El sistema debe de finalizar el mayor numero de procesos en por unidad de tiempo.

·         Maximizar el Tiempo de Respuesta: Cada usuario o proceso debe observar que el sistema les responde consistentemente a sus requerimientos.

·         Evitar el aplazamiento indefinido: Los procesos deben terminar en un plazo finito de tiempo.

·         El sistema debe ser predecible: Ante cargas de trabajo ligeras el sistema debe responder rápido y con cargas pesadas debe ir degradándose paulatinamente. Otro punto de vista de esto es que si se ejecuta el mismo proceso en cargas similares de todo el sistema, la respuesta en todos los casos debe ser similar.

Características a considerar de los procesos

·         No todos los equipos de cómputo procesan el mismo tipo de trabajos, y un algoritmo de planificación que en un sistema funciona excelente puede dar un rendimiento pésimo en otro cuyos procesos tienen características diferentes. Estas características pueden ser:

·         Cantidad de Entrada/Salida: Existen procesos que realizan una gran cantidad de operaciones de entrada y salida (aplicaciones de bases de datos, por ejemplo).

·         Cantidad de Uso de CPU: Existen procesos que no realizan muchas operaciones de entrada y salida, sino que usan intensivamente la unidad central de procesamiento. Por ejemplo, operaciones con matrices.

·         Procesos de Lote o Interactivos: Un proceso de lote es más eficiente en cuanto a la lectura de datos, ya que generalmente lo hace de archivos, mientras que un programa interactivo espera mucho tiempo (no es lo mismo el tiempo de lectura de un archivo que la velocidad en que una persona teclea datos) por las respuestas de los usuarios.

·         Procesos en Tiempo Real: Si los procesos deben dar respuesta en tiempo real se requiere que tengan prioridad para los turnos de ejecución.

·         Longevidad de los Procesos: Existen procesos que tipicamente requeriran varias horas para finalizar su labor, mientras que existen otros que solonecesitan algunos segundos.

Planificación apropiativa o no apropiativa (preemptive or not preemptive)
La planificación apropiativa es aquella en la cual, una vez que a un proceso le toca su turno de ejecución ya no puede ser suspendido, ya no se le puede arrebatar la unidad central de procesamiento. Este esquema puede ser peligroso, ya que si el proceso contiene accidental o deliberadamente ciclos infinitos, el resto de los procesos pueden quedar aplazados indefinidamente. Una planificación no apropiativa es aquella en que existe un reloj que lanza interrupciones periodicas en las cuales el planificador toma el control y se decide si el mismo proceso seguirá ejecutándose o se le da su turno a otro proceso. Este mismo reloj puede servir para lanzar procesos manejados por el reloj del sistema. Por ejemplo en los sistemas UNIX existen los 'cronjobs' y 'atjobs', los cuales se programan en base a la hora, minuto, día del mes, día de la semana y día del año.
En una planificación no apropiativa, un trabajo muy grande aplaza mucho a uno pequeño, y si entra un proceso de alta prioridad esté también debe esperar a que termine el proceso actual en ejecución.

2.4 CONCURRENCIA Y SECUENCIABILIDAD

La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el diseño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:

• Varias aplicaciones: La multiprogramación se creó para permitir que el tiempo de procesador

De la máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas. 159 Digitalización con propósito académico Sistemas Operativos

160 Concurrencia: Exclusión mutua y sincronización

• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

• Estructura del sistema operativo:Las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos. Debido a la importancia de este tema, hay cuatro capítulos de este libro dedicados a conceptos relacionados con la concurrencia.

La concurrencia es el punto clave de los tres campos anteriores y fundamentales para el diseño de sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes:

• Varias aplicaciones: La multiprogramación se creó para permitir que el tiempo de procesador

De la máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas. 159 Digitalización con propósito académico Sistemas Operativos

160 Concurrencia: Exclusión mutua y sincronización

• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.

• Estructura del sistema operativo:Las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos. Debido a la importancia de este tema, hay cuatro capítulos de este libro dedicados a conceptos relacionados con la concurrencia.

2.3 PROCESOS LIGEROS (HILO O HEBRAS).

En la mayoría de los sistemas operativos, estas dos características son, de hecho, la esencia de un proceso. Sin embargo, algunos argumentos pueden convencer de que estas dos características son independientes y que deben ser tratadas de manera independiente por el sistema operativo. Esto se hace así en una serie de sistemas operativos, en particular en algunos sistemas operativos de desarrollo reciente. Para distinguir estas dos características, la unidad de expedición se conoce cornohilo (thread) o proceso ligero (lightweight process),mientras que a la unidad de propiedad de los recursos se le suele llamar proceso o tarea.

Varios hilos en un solo proceso

La utilización que más salta a la vista del concepto de hilo es la de una disposición en la que pueden existir varios hilos dentro de un mismo proceso. Algo aproximado a este enfoque es lo que se hace en MVS. De una forma más explícita, este enfoque es el asumido por Windows NT,OS/2, la versión que tiene Sun del UNIX y un importante sistema operativo conocido como Mach LAC92, RASH89, TEVA89]. Mach es una evolución ampliada de UNIX que se utiliza en las estaciones Next y que forma la base de la versión de UNIX de la Fundación para el Software Abierto (OSF, Open Software Foundation). Este apartado describe el enfoque tornado en Mach; las técnicas utilizadas en Windows NT y MVS se discuten en la sección 3.5.Digitalización con propósito académico Sistemas Operativos

136 Descripción y control de procesos

Mach está diseñado específicamente para trabajar en un entorno multiprocesador, aunque también se adapta bien a los sistemas monoprocesadores. En Mach, una tarea se define como la unidad de protección o unidad de asignación de recursos. A las tareas se les asocian los siguientes elementos:

• Un espacio de direcciones virtuales, que contiene la imagen de la tarea

• Acceso protegido a los procesadores, otros procesos (para la comunicación entre procesos),

Archivos y recursos de E/S (dispositivos y canales)

En una tarea puede haber uno o más hilos, cada uno con lo siguiente:

• El estado de ejecución del hilo (Ejecución, Listo, etc.)

• El contexto del procesador, que se salva cuando no está ejecutando; una forma de contemplar

Al hilo es con un contador de programa independiente operando dentro de una tarea

• Una pila de ejecución

• Almacenamiento estático para las variables locales

• Acceso a la memoria y a los recursos de la tarea, que se comparten con todos los otros

Hilos de la tarea

Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: Se tarda mucho menos tiempo en crear un nuevo hilo en un proceso existente que en crear una nueva tarea, menos tiempo para terminar un hilo y menos tiempo para cambiar entre dos hilos de un mismo proceso. Por tanto, si hay una aplicación o una función que pueda implementarse como un conjunto de unidades de ejecución relacionadas, es más eficiente hacerlo con una colección de hilos que con una colección de tareas separadas.8 Algunos estudios llevados a cabo por los desarrolladores de Mach demuestran que la aceleración en la creación de procesos, comparada con la de Las implementaciones de UNIX que no utilizan hilos, está en un factor de 10 [ITEVA87]. Un ejemplo de aplicación que podría hacer uso de hilos es un servidor, como puede ser un servidor de archivos de una red de área local. Cada vez que llegue una solicitud de un nuevo archivo, se puede generar un nuevo hilo para el programa de gestión de archivos. Puesto que el servidor debe manejar muchas solicitudes, se crearán y destruirán muchos hilos en un corto periodo de tiempo. Si el servidor es un multiprocesador, se pueden ejecutar varios hilos de una misma tarea simultáneamente y en diferentes procesadores. Los hilos son también útiles en los monoprocesadores para simplificar la estructura de los programas que lleven a cabo diversas funciones. Otros ejemplos de uso efectivo de los hilos son en las aplicaciones de proceso de comunicaciones [COOP90] y en los supervisores de transacciones. Otra forma en la que los hilos aportan eficiencia es en la comunicación entre diferentes programas en ejecución. En la mayoría de los sistemas operativos, Ia comunicación entre procesos independientes requiere la intervención del núcleo para ofrecer protección y para proporcionar los mecanismos necesarios para la comunicación. Sin embargo, puesto que los hilos de una misma tarea comparten memoria y archivos, pueden comunicarse entre sí sin invocar al núcleo. [ETW88] da cuatro ejemplos de uso de los hilos en un sistema de multitarea.

2.2 ESTADOS Y TRANSICIONES DE PROCESO

La responsabilidad principal del sistema operativo es el control de la ejecución de los procesos; esto incluye la determinación de las pautas de intercalado que se van a seguir y la asignación de recursos a los procesos. Para poder diseñar el sistema operativo de una forma efectiva, se necesita tener un modelo claro del comportamiento de un proceso.

El primer paso que controle los procesos es describir el comportamiento que se los procesos.

El modelo más sencillo que puede construirse tiene en cuenta que, en un momento dado, un proceso puede estar ejecutándose en el procesador o no. Así pues, un proceso puede estar en uno de dos estados: Ejecución o No Ejecución. Cuando el sistema operativo crea un nuevo proceso, éste entra en el sistema en estado de No Ejecución. De este modo, el proceso existe, es conocido por el sistema operativo y está esperando la oportunidad de ejecutarse. De cuando en cuando, el proceso que está ejecutando será interrumpido y el programa distribuidor del sistema operativo seleccionará un nuevo proceso para que se ejecute. El proceso anterior pasa del estado de Ejecución al estado de No Ejecución y uno de los demás procesos pasará al estado de Ejecución. Incluso en este modelo tan simple ya se comienzan a apreciar algunos de los elementos de diseño del sistema operativo. Cada proceso debe representarse de forma que el sistema operativo pueda seguirle la pista. Esto es, debe haber información relativa a cada proceso, incluyendo su estado actual y su posición en memoria. Aquellos procesos que no están ejecutándose tienen que guardarse en algún tipo de cola, para que esperen su tumo de ejecución.

Estados de un proceso

Un total de nueve estados de proceso son los reconocidos por el sistema operativo UNIX; éstos están reflejados en La tabla 3.13 y un diagrama de transición de estados se muestra en La figura 3.16. Esta figura es bastante similar a la figura 3.7, con los dos estados de Dormido de UNIX correspondientes a los dos estados de Bloqueado. Las diferencias pueden resumirse rápidamente a continuación:

• UNIX emplea dos estados de Ejecución, que indican si el proceso está ejecutando en modo de usuario o en modo núcleo.

• Se hace una distinción entre los estados: Listo para Ejecutar y en Memoria, frente al estado de Expulsado. Estos dos estados son, básicamente, el mismo, como se indica por la línea de puntos que los une. Se hace la distinción para enfatizar la forma en que se pasa al estado Expulsado. Cuando un proceso esté ejecutándose en modo núcleo (como resultado de una llamada del supervisor, una interrupción de reloj, o una interrupción de E/S), llegara un momento en el que el núcleo termine su trabajo y esté listo para devolver el control al programa de usuario. En este punto, el núcleo puede decidir expulsar el proceso en curso en favor de alguno que esté listo y tenga mayor prioridad  

El modelo de transición de estados que se ha desarrollado. (Las líneas discontinuas en la figura indican transiciones posibles pero no necesarias). Las nuevas e importantes transiciones son las siguientes:

• Bloqueado _ Bloqueado y suspendido: Si no hay procesos Listos, entonces al menos un proceso Bloqueado se expulsa para dar cabida a otro proceso que no esté bloqueado. Esta transición puede hacerse aun cuando hay procesos listos disponibles, cuando el sistema operativo determina que el proceso que está actualmente en Ejecución o un proceso Listo que serla conveniente expedir requiere más memoria principal para mantener un rendimiento adecuado.

• Bloqueado y suspendido _ Listo y suspendido: Un proceso en estado Bloqueado y suspendido se pasa al estado Listo y suspendido cuando ocurre el suceso que estaba esperando. Nótese que esto requiere que esté accesible para el sistema operativo la información relativa a los procesos Suspendidos.

• Listo y suspendido _ Listo: Cuando no hay procesos Listos en la memoria principal, el sistema operativo tendrá que traer uno para continuar la ejecución. Además, puede darse el caso de que un proceso en estado Listo y suspendido tenga una prioridad mayor que la de un proceso en estado Listo. En tal caso, el diseñador del sistema operativo puede decidir que es más importante tomar el proceso de mayor prioridad que minimizar el intercambio.

• Listo _ Listo y suspendido: Generalmente, el sistema operativo prefiere suspender a un proceso Bloqueado en vez de a uno Listo, ya que el proceso Listo podría ejecutarse de inmediato, mientras que el proceso Bloqueado estará ocupando espacio en la memoria principal sin poder ejecutarse. Sin embargo, puede ser necesario suspender un proceso Listo si ésta es la única forma de liberar un bloque lo suficientemente grande de memoria principal. Por último el sistema operativo puede escoger suspender un proceso Listo de más baja prioridad en lugar de uno Bloqueado que sea de prioridad más alta si él cree que el proceso Bloqueado pronto estará listo.

Estados de un Proceso en UNIX Ejecución en modo de usuario Ejecutando en modo usuario. Ejecución en modo del núcleo Ejecutando en modo del núcleo. Listo para ejecutar y en memoria Listo para ejecutar tan pronto como el núcleo lo planifique. Dormido y en memoria No dispuesto para ejecutar hasta que se produzca un suceso; el proceso está en memoria principal.

Listo para ejecutar y descargado El proceso está listo para ejecutar, pero se debe cargar el proceso en memoria principal antes de que el núcleo pueda planificarlo para su ejecución. Dormido y descargado El proceso está esperando un suceso y ha sido expulsado al almacenamiento secundario. Expulsado El proceso retorna del modo núcleo al modo usuario pero el n6cleo lo expulsa y realiza un cambio de contexto para para planificar otro proceso. Creado El proceso está recién creado y aún no está aún listo para ejecutar. Zombi El proceso ya no existe, pero deja un registro para que lo recoja el proceso padre.

2. ADMINACION DE PROCESOS Y DEL PROCESADOR

2.1 CONCEPTO DE PROCESADO

El concepto de proceso es fundamental en la estructura de los sistemas operativos. Este término fue acuñado por primera vez por los diseñadores de Multics en los años 60. Es un término algo más general que el de trabajo. Se han dado muchas definiciones para el término proceso, entre las que se incluyen las siguientes:

• Un programa en ejecución

• El "espíritu animado" de un programa

• La entidad que puede ser asignada al procesador y 

ejecutada por él.

 
El concepto de proceso debe quedar más claro a medida que se avance. Tres líneas principales en el desarrollo de los sistemas informáticos crearon problemas de tiempos y de sincronización que contribuyeron al desarrollo del concepto de proceso: la operación por lotes con multiprogramación, el tiempo compartido y los sistemas de transacciones en tiempo real. Como se ha visto, la multiprogramación fue diseñada para mantener ocupados a la vez tanto procesador como los dispositivos de E/S, incluyendo los dispositivos de almacenamiento, de modo que se alcance la mayor eficiencia posible. La clave de este mecanismo es que, como respuesta a las señales que indiquen que ha terminado una transacción de E/S, el procesador cambia entre los diversos programas que residen en la memoria principal. Una segunda línea de desarrollo fue la de los sistemas de tiempo compartido de propósito general. La justificación de tales sistemas es que los usuarios del computador son más productivos si pueden interactuar directamente con el computador desde algún tipo de terminal. En este caso, el objetivo clave del diseño es que el sistema sea sensible a las necesidades del usuario individual y que, además, por razones de coste, pueda dar soporte simultáneo a muchos usuarios. Estos objetivos son compatibles debido al tiempo de reacción relativamente lento que tienen los usuarios. Por ejemplo, si un usuario típico necesita, en promedio, 2 segundos de tiempo de procesamiento por minuto, entonces cerca de 30 usuarios deberían ser capaces de compartir el mismo sistema sin interferencias notables. Por supuesto, debe tenerse en cuenta la sobrecarga que impone el propio sistema operativo.