[002] Sistemas Operativos - Gestion de Procesos

��

��

Como se vio en la Introducción, en los sistemas operativos actuales se puededisponer de varios programas en memoria que se pueden ejecutar, dependiendo dela política de planificación, de una forma más o menos simultánea.

En este capítulo nos vamos a ocupar de cómo el sistema operativo se encarga decontrolar todos los procesos cargados en memoria, de la asignación de la CPU acada uno de los procesos, y, cuando se trate de procesos cooperantes, de lacomunicación y sincronización entre ellos.

��

��

�� Sabemos que la CPU realiza ciertas actividades. En un sistema de tratamiento porlotes (��), se ejecutan trabajos; en un entorno de tiempo compartido hayprogramas de usuarios, o tareas; incluso en un ordenador personal, hoy día unusuario puede ejecutar varios programas simultáneamente, uno interactivo, y otrosen segundo plano (�� . La cuestión es cómo llamar a todas estasactividades que realiza la CPU. Pues bien, a estas actividades las denominaremos��.

�� Se han oído muchas definiciones de proceso, pero, sin duda, la más popular yacertada es la que dice que “��”.

Ya que no es nada fácil dar una definición autoexplicativa de lo que es un proceso,vamos a tratar de explicarlo mediante ideas y ejemplos. Ante todo, se debe tenermuy presente que un proceso asocia programa+actividad.

Cuando decimos que un proceso es un programa en ejecución, nos referimos alhecho de llevar a cabo o realizar las instrucciones que contiene el programa en elorden establecido. Un programa es una lista de instrucciones escritas en un papel,un fichero en disquete, disco duro, memoria RAM o cualquier otro soporte, pero elsimple hecho de que estas instrucciones estén escritas no implica que se esténllevando a cabo. Pues bien, cuando se leen estas instrucciones y se hacen ejecutar,entonces ya tenemos programa+actividad, es decir, un proceso.

Hacemos hincapié en �� para diferenciarlo bien de un mero programa, ya queuna característica básica de los programas es que son estáticos. Ya hemos dichoque un programa es una secuencia de órdenes que, por mucho que la miremos, novaría nunca. Las variables no tienen valores, las rutinas no tienen dirección, lascondiciones están sin evaluar. Un programa es simplemente ��

En cambio, un proceso es dinámico. Tiene vector de estado indicando el momento yestado de su ejecución, las variables tienen valores, las rutinas se encuentran enalguna dirección de memoria, y las condiciones son evaluables. El proceso es ��

Un ejemplo que puede describir la relación programa-proceso puede ser el manualde montaje de un aeromodelo que viene despiezado. Las instrucciones de montajeque vienen en la caja son algo estático (por eso aunque dejemos mucho tiempo lasinstrucciones en la caja, el aeromodelo no aparece construido al cabo de un tiempo.Sin embargo, cuando cogemos las instrucciones y empezamos a hacer lo queindican, es cuando empieza la actividad, entonces comienza el �� de montaje.

Rolito

Highlight

Rolito

Highlight

Rolito

Highlight

��

��

6LVWHPDV�2SHUDWLYRV�, *HVWLyQ�GH�3URFHVRV��

��

��

��

�� →

�� ! ��!��

"��

�� !��

��

�� #� � ��

��

$ � �� →

%�� ! �� !��

%�� !��

%�� !��

��

� � ��

��&

�� ' ��(

�")��*)

* � � ��

+�,��+�,��

��

��

Si en la construcción del aeromodelo, quien lleva a cabo las instrucciones delmanual de montaje es la persona, que lee las instrucciones y las va ejecutando; enun ordenador, el ente que va leyendo las instrucciones del programa (que está enmemoria) y ejecutándolas, es la CPU. Así, tenemos que el tándemprograma+procesador es el que hace que el estado de desarrollo de un determinadotrabajo evolucione y cambie de un estado a otro.

Al igual que para la construcción del aeromodelo se necesita un área de trabajo (unamesa o algo similar), para la ejecución de un programa, también se requiere un áreade trabajo, esto es, ��del proceso. La pila es la zona de memoria en la que seguardan los parámetros, variables locales, direcciones de retorno de subprogramasy, en general, los datos temporales del proceso. Un proceso también se caracterizaporque en un momento dado de su ejecución dispone de ciertos valores en losregistros del procesador, entre ellos, el �� que contiene ladirección de la instrucción que va a ejecutar el proceso a continuación. Así, elContador de Programa es el registro que indica el punto de ejecución del programaen el que se encuentra el proceso.

Se debe tener en cuenta que la relación entre un programa y su proceso no esbiunívoca. Esto se debe al hecho de que en un momento dado puede haber variosprocesos correspondientes al mismo programa. Por ejemplo, en una clase detrabajos manuales pueden estar escritas en la pizarra las instrucciones de montajede un aeromodelo (un programa) y todos los alumnos están montando unaeromodelo siguiendo las mismas instrucciones (varios procesos). Un ejemplo másinformático puede ser el de varios alumnos que, en un momento dado, estánutilizando el editor de texto en distintos terminales de un sistema de tiempocompartido. Hay un único programa editor de texto, pero puede haber variosprocesos simultáneos ejecutando tal programa.

�� Como ya sabemos, en un sistema multiprogramado se pueden ejecutarsimultáneamente varios programas, es decir, en un momento dado puede habervarios procesos. En un sistema con un único procesador no se puede decir quehaya varios programas ejecutándose estrictamente de una forma simultánea. Enrealidad, la posesión del procesador se va repartiendo entre los distintos procesos,dando lugar a una ejecución pseudoparalela. No obstante, por simplicidad, nosreferiremos, en general, a ejecución simultánea o paralela, tanto si es estricta(sistema multiprocesador) como si no lo es (con un solo procesador).

El ��!�� de un proceso se define como la información necesaria para especificarcompletamente su estado actual. Esto incluye toda la información que ha desalvarse cuando un proceso pierde la posesión de la CPU, y hay que restaurarcuando se le vuelve a conceder la posesión del procesador.

Rolito

Highlight

Rolito

Highlight

��

�� "

El contexto de un proceso, dependiendo del lugar donde reside la información, estáformado por tres tipos de información:

• Bloque de Control de Proceso (BCP)• Contexto de Memoria• Contexto del Procesador

El #��$�� (o Descriptor de Proceso) comprende lainformación que siempre está en la memoria principal durante la existencia delproceso. El BCP contiene la información relativa a un proceso que requiere elsistema operativo para gestionarlo. Igual que en una empresa se dispone de lasfichas de los empleados, con los datos necesarios para la administración (Datospersonales, profesionales, salarios, horas extraordinarias, etc.), el sistema operativodispone de los BCP de cada uno de los procesos que tiene en cada momento.Aunque el contenido de los descriptores de procesos varía de un sistema a otro, enla Figura 2 se puede ver un ejemplo con algunos datos típicos que suelen contener.A lo largo de este capítulo se irá viendo el significado y utilidad de estos datos delBCP, así como las estructuras de datos que contiene el sistema operativo paramantener los BCP’s de todos los procesos.

El ��!�� %�� contiene lo que es el programa en sí, es decir, lasinstrucciones y los datos del programa. Esta parte solamente necesita estar enmemoria principal cuando el proceso está realmente en ejecución, o sea, que tienela CPU asignada; el resto del tiempo, el contexto de memoria puede encontrarse endisco, liberando así espacio de memoria principal.

El ��!�� es la parte del contexto del proceso almacenado enlos registros del procesador. En estos registros se mantienen datos tales como elContador de Programa, el estado de la CPU, el puntero de la pila utilizada por elproceso, registros de control y registros de propósito general para mantener datosde las variables o constantes del programa.

Como ya hemos dicho, el BCP es algo así como la ficha de control del proceso, poresto, en él también se encuentra la información necesaria para poder acceder tantoal contexto de memoria como al del procesador.

Rolito

Highlight

Rolito

Highlight

Rolito

Highlight

Rolito

Highlight

Rolito

Highlight

��

��& ��


�� - ��

�� !�*�)��!��

. �� /� ��

�!�- �� 0��1

� !��

� ��. ��

� �� !�� 2" ��3

�� DESCRIPTOR_PROCESO ��

Id_Proceso

Siguiente

Estado

Puntero_Pila

Memoria_Utilizada

Ficheros_Abiertos

Proceso_Padre

Procesos_Hijos

Dormido_Hasta

��;

�� 4�� !��

��

�� '

�� En la Introducción ya se vio, por encima, la utilidad de ejecutar varios programas deforma simultánea para evitar el desaprovechamiento de los tiempos de espera deCPU a las respuestas de los dispositivos periféricos en las operaciones deentrada/salida que realiza un proceso.

Otra justificación de la ejecución paralela de programas viene dada por las leyes dela física, pues según la Teoría de la Relatividad de Albert Einstein es imposibletransmitir señales eléctricas a más velocidad que la de la luz, esto es, unos 30cmpor nanosegundo. Esto quiere decir que el tiempo mínimo que puede tardar entransmitirse una señal entre dos componentes de un ordenador separados 30cm es1ns. O sea, que los ordenadores tendrían que empezar a fabricarse cada vez máspequeños, pero claramente, sabemos que esto tiene ciertas limitaciones. Por otraparte, algunos programas (cálculo científico, tiempo real, etc.) requieren, a menudo,ciertas velocidades de ejecución, para que el resultado sea exitoso. Una forma deconseguir que un programa se ejecute más rápidamente que ejecutando unainstrucción tras otra, consiste en dividir el programa en varias tareas o procesos yejecutándolos en paralelo. Un símil de la vida real puede ser el proceso defabricación de los automóviles. Las cadenas de montaje de los coches no fabricanprimero las ruedas, luego el motor, a continuación el chasis, después la carrocería,luego los cristales, ...; sino que cada uno de estos elementos se fabrica porseparado de forma paralela y simultánea, y cuando están todos construidos, serealiza el proceso de ensamblaje para formar el automóvil completo. De esta formase consigue construirlo en bastante menos tiempo.

Ya tenemos, por tanto, dos buenas razones para la multiprogramación:

• Los procesos cooperantes, para realizar un trabajo en conjunto.

• Mejorar el rendimiento del ordenador, aprovechando la CPU en sus tiempos deespera por dispositivos de E/S, dando lugar a sistemas multiusuario osimplemente de multiproceso.

No debemos confundir un sistema �� con ��. Un entornomultiproceso es el que permite varios procesos simultáneos, por ejemplo, unapersona en un terminal con ventanas tal que en cada ventana tiene distintosprocesos en ejecución (un editor de texto, un reloj, un videoclip, etc.). En estesistema es posible que no haya más puestos de trabajo o terminales, con lo quesería un entorno multiproceso monousuario. Si se dispone de varios terminales enun sistema, entonces, además de multiproceso, es multiusuario.

��

��( ��


*�� .�!�� ! !��

�� ! �� !�� * �� !%��! 5 �� !��0�� !��

� �� !��

�� 6�

!��,

7�*�)�%�,��8��9

�")��*:.��$)��:":%�%)�2�� ! !�3

+�.�,�%�$��"�)�;�"�:�.�:��8��+

��

��

.�!��! 4�� !��,� ��

�� 2�� 3

.�!�� ≠�.�!��

��

�� )

��

Sabemos que para que un programa se ejecute, hay que convertirlo en proceso, ypara que éste evolucione de un estado a otro se requiere un procesador. Sihablamos de sistemas multiproceso, es decir, que hay varios programassimultáneamente en memoria, lo más conveniente para la ejecución más rápida esasignar un procesador a cada uno de los procesos, para que evolucionen todos deuna forma realmente paralela o simultánea. Este es el caso de los ordenadores conmúltiples procesadores, en los que en un momento dado se encuentran realmenteen ejecución varios programas. Si bien esta es la forma más rápida de ejecutarmúltiples programas, también resulta ser, obviamente, la más cara. No solamentepor la cantidad de hardware utilizado (cuando menos, varias CPU’s), sino tambiénpor el hardware y software adicional necesario para poder sincronizar y gestionarmúltiples CPU’s, algo mucho más complejo que cuando solamente se dispone de unúnico procesador. (Resultan mucho más sencillos los departamentos de personal,marketing, fabricación, distribución etc. de una empresa de 2, 3 o 4 empleados, quelos de una multinacional de miles de empleados).

Ya que la mayoría de los ordenadores actuales de propósito general constan de unsólo procesador, vamos a centrarnos aquí en los ordenadores monoprocesadores,dejando los de múltiples procesadores para otras asignaturas de arquitecturasavanzadas.

Si tenemos un sistema operativo multiproceso y contamos con un único procesador,solamente tenemos una elección: ��.De esta manera, lo que conseguimos es simular una máquina multiprocesador, esdecir, tendremos un pseudoparalelismo en la ejecución de los procesos. Así, aunqueno obtengamos todas las ventajas de una ejecución puramente paralela, síaprovecharemos el hecho de que durante la ejecución de un programa hay muchosmomentos en que no se puede continuar su ejecución hasta que no se produzcaalgún evento externo a la CPU, como por ejemplo la realización de una operaciónsolicitada a un dispositivo de E/S, la pulsación de un carácter en el teclado, lallegada de un carácter por la línea de comunicaciones, una interrupción generadapor un detector, etc.

Quizás nos puedan servir como ejemplo las partidas de ajedrez simultáneas quemantienen los maestros de ajedrez con 20 principiantes. Cuando el maestro realizauna jugada con un principiante, éste tarda mucho tiempo hasta que decide mover;mientras tanto, el maestro puede realizar jugadas con el resto de los aprendices, yseguramente, le dará tiempo a hacer un movimiento con cada uno de los rivalesantes de que el primero de ellos se haya decidido a mover una figura.

En este ejemplo tan optimista, esta partida simultánea se realiza en 1/20 del tiempoque se tardaría si el maestro primero se dedicase por entero a jugar una partida conel primer aficionado, hasta finalizarla; luego comenzar otra partida con el segundo yasí sucesivamente hasta haber jugado las 20 partidas. En los casos reales denuestros ordenadores, el reparto de la CPU no suele resultar tan provechoso comoen el caso del maestro de ajedrez, pues a menudo, también hay procesos a los que

Rolito

Highlight

Rolito

Highlight

��

��* ��


��*�� .�!��

,�� ,��

��

<�5�#� ��!��#��!��

2* ��! !��3

<�5�#� �� !�� !�� 7 9

�� '

�� (

�� =

.�!�� .�� !��! 4��

��

��

��

��

se les quita la posesión de la CPU antes de que ellos la liberen por una de susesperas a un evento externo, por lo que nos encontramos con procesos que estánparados cuando sí podrían ejecutarse de tener una CPU disponible. En el peor delos casos, es decir cuando se disponga de varios procesos que no tienen esperasde E/S, la diferencia entre ejecutarlos en un entorno multiprocesador omonoprocesador es la que se muestra en el gráfico de la Figura 5, en la que seaprecia que la CPU se reparte en porciones de tiempo entre los distintos procesos,por lo que mientras uno se ejecuta, los demás deben esperar su turno de CPU. Eneste caso decimos que la utilización de la CPU está ��.

��

Anteriormente hemos visto que un ejemplo del ��+�� de un proceso podríaestar caracterizado por esta secuencia:

1. Se está ejecutando (posee la CPU).

2. Realiza una operación de E/S y se pone a esperar la respuesta (abandona laCPU).

3. Cuando recibe la respuesta de la operación de E/S desea continuar laejecución (necesita otra vez la CPU).

También hemos visto con anterioridad que en otras ocasiones, el tiempo de CPU sereparte en porciones entre todos los procesos que lo solicitan, por lo que un procesopuede ver cómo pierde la posesión del procesador, de forma involuntaria, cuando sele acaba la porción de tiempo que tenía asignada.

Este ciclo de vida de un proceso lo podemos ver en la Figura 6. En esta figura, loscírculos son recursos o condiciones deseadas por un proceso, mientras que losrectángulos representan las colas de procesos que esperan por tales recursos. Así,vemos que un proceso recién creado inmediatamente quiere ejecutarse, para lo cualnecesita la CPU, por lo que pasa a la cola de los procesos que esperan por elprocesador (cola de procesos ��). Una vez que le llega el turno, ejecutalas instrucciones, hasta que por uno de los motivos mencionados (operación de E/S,fin de la porción de tiempo, etc.) pierde la posesión de la CPU y pasa a la cola delrecurso solicitado (Disco 1, Unidad de Cinta 3, esperar a las 2:00 de la mañana). Sila posesión del procesador se ha perdido por finalizar la porción de tiempo asignadoo bien porque un proceso de mayor prioridad requiere el procesador, el recurso quenecesita el proceso expulsado (o expropiado) es la propia CPU, por lo que pasa a lacola correspondiente (la de los procesos preparados).

Este ciclo se repite una y otra vez hasta que el proceso ejecuta su última instrucción,o sea, que finaliza el trabajo, con lo que voluntariamente cede el control de la CPU yda por concluida su existencia como proceso.

Así, llegamos ya al diagrama básico de estados de un proceso, que lo vemosrepresentado en la parte superior de la Figura 7. En él tenemos que un proceso estáejecutando instrucciones (,�� ,��), esperando a que le concedan la CPU

��

��

para ejecutar instrucciones (��), o esperando a que se produzca algúnevento externo (,��,��o�-��$��).


6LVWHPDV�0XOWLSURFHVR ��!��

�"��:":-) ��,&UHDFLyQ 7HUPLQDFLyQ��

loadstoreaddstoreread fichero

storeincrementwrite fichero

loadstoreaddstoreread fichero

��

(VSHUD�(�6

(VSHUD�(�6

(VSHUD�(�6

3HULRGR&38

3HULRGR&38

3HULRGR&38

3HULRGR(�6

3HULRGR(�6

3HULRGR(�6

-��'

��=

��!�6��

([SXOVLyQ

',6&2��

'RUPLGR�KDVWDODV��

&,17$��

Vamos a ver cómo se producen las transiciones entre estos tres estados.

��→��Inicialmente, al crear un proceso, no puede pasar directamente al estado deEspera, pues no se ha ejecutado ninguna instrucción que así se lo indique; porlo tanto, expresa su necesidad de ejecución entrando en la cola de procesosPreparados.

��→�,��,��Una vez que el proceso está preparado, solamente tiene que esperar a que lellegue el turno. Los turnos del procesador se establecen en función de lapolítica de planificación de la CPU. Cuando le llegue el turno tomará posesióndel procesador y empezará a ejecutar instrucciones.

Como podemos ver en el gráfico, desde el estado de Ejecución se puede pasara cualquiera de los otros dos estados (Espera y Preparado).

��

��


*�� .�!�� !��

��

��

��

$ ��

��

MAX_PROCESOS : constant 100;

type ID_PROCESOS is INTEGER range 0..MAX_PROCESOS;

type� �� isrecord

Primero : ID_PROCESOS := 0;

Ultimo : ID_PROCESOS := 0;

end record;

�� : array [1..MAX_PROCESOS] of DESCRIPTOR_PROCESOS;

�� : ID_PROCESOS;

�� : COLA_PROCESOS;

�� : COLA_PROCESOS;

��

��

,��,��→��Pasará a Preparado si abandona la CPU involuntariamente, es decir si se leexpulsa (o expropia), bien porque haya terminado su porción de tiempo, oporque haya pasado a Preparado otro proceso de mayor prioridad.

,��,��→�,��En cambio, pasa al estado de Espera si cede voluntariamente el procesador,por tener que esperar a que se produzca un evento externo a la CPU.

,��→��Desde el estado de Espera no se puede volver directamente a Ejecución, sinoque cuando se haya cumplido el evento externo, para recuperar la posesión delprocesador hay que pasar de nuevo por la cola de los procesos preparados.Así tenemos que para conseguir la posesión de la CPU siempre hay que pasarpor su cola correspondiente (como un recurso más que es).

,��,��→�.��Como ya hemos dicho antes, el proceso termina cuando ejecuta su últimainstrucción, luego siempre pasará al estado de Terminado desde Ejecución.

Como hemos visto, a medida que progresa su ejecución, un proceso va cambiandode estado. A excepción de los estados obvios de �� y ��, unproceso tiene dos estados básicos: �� y ��

��+�/ El proceso no depende de ninguna condición externa al procesadorpara poder continuar su ejecución. O bien se está ejecutando, o seencuentra esperando en la cola de procesos Preparados a que leconcedan la posesión de la CPU.

,��,��/ El proceso no puede continuar la ejecución. Está bloqueado, a laespera de que se cumpla un evento externo a la CPU, tal como unarespuesta de un dispositivo de E/S, que llegue una hora determinada,etc.

Vistos los estados que puede tener un proceso y las transiciones entre ellos, nosinteresa saber ��+�� +�� , cómo se realizan estas colas de procesos y cómo se sabe qué procesoestá en ejecución.

En un apartado anterior hemos visto que hay una estructura de datos que contienetoda la información de control que requiere el sistema operativo para ocuparse de lagestión o administración del proceso. Nos estamos refiriendo al Descriptor deProceso o Bloque de Control de Proceso (BCP). Pues bien, entonces lo que elsistema operativo necesita es mantener la colección de todos los BCP’s de losprocesos existentes en cada momento. Esta colección de BCP’s se puede organizarde distintas maneras: mediante una cola estática, con una cola dinámica, osimplemente utilizando una tabla, es decir, un vector o array de BCP’s. Así vemos

Rolito

Highlight

Rolito

Highlight

Rolito

Highlight

��

�� "


*�� .�!�� !��

�� >!��

��?�@��,��8�1�A

�"��:":-)*

�� >!��

-��'

�� >!��

��'

�� >!��

$ ��!�'

*��! �*��!��*��B �*��' *��!�*��! �*��(��*��!�*��!

��

$� !�� C��

C��D C��(

C��= C��B C��'

C��E

' ( = �B E ��A �D F �G

��

��& ��

en el recuadro inferior de la Figura 7 la declaración de Procesos como un array detamaño Max_Procesos y formado por elementos de tipo Descriptor_Procesos.De esta manera, el sistema operativo puede consultar el BCP de cada procesoaccediendo a la tabla Procesos utilizando el identificador del proceso como índice.

También se puede apreciar que la variable En_Ejecucion contiene el identificadordel proceso que actualmente se encuentra en posesión de la CPU. Por último,podemos observar la implementación del estado de Preparado, o sea, una variablede tipo Cola_Procesos (que hace de cabecera de una cola), que no es más queun registro con dos campos que indican, respectivamente, cuál es el primero y elúltimo elemento de una cola de procesos. Cada elemento de la cola de procesos esun BCP, y si nos fijamos en su declaración de la Figura 3 podemos ver que graciasal campo Siguiente, que es el enlace, resulta fácil formar dicha cola. El campoSiguiente contiene un identificador de proceso (el siguiente en la cola) o bien elvalor NIL si es el último de la cola.

Habiendo visto cómo se construye la cola de Preparados, resulta fácil imaginar quelas colas de procesos para cada uno de los recursos por los que se puede esperar(dispositivos de E/S, etc.) se implementan de igual forma.

En la Figura 8 se muestra un ejemplo del estado de los procesos en un momentodeterminado. Por una parte tenemos que el proceso en Ejecución es el 6, y que lacola de los procesos Preparados está formada por los procesos 7 y 2. No hayningún proceso esperando para acceder al Disco_1, mientras que por la Cinta_3están esperando los procesos 3, 4 y 1. Por último, tenemos al proceso 5 que estáesperando por el Terminal_1. En la parte inferior de esta Figura 8 tenemos la tablade BCP’s en la que se pueden observar los valores que toman los camposSiguiente para formar las colas de procesos de este ejemplo.

��!� ��"�� #��"��Cuando un proceso en ejecución pierde la posesión de la CPU, se debe a uno delos siguientes motivos:

• Llamada al sistema• Interrupción• Fin del proceso

Está claro que ante ciertas llamadas al sistema (una petición de E/S, dormir, etc.) elproceso en cuestión queda bloqueado, sin poder continuar la ejecución deinstrucciones, hasta que se atienda el servicio solicitado; por esto, cede la posesióndel procesador para que pueda ejecutar instrucciones otro proceso que estépreparado.

También puede ocurrir que una interrupción anuncie el final de la actual posesióndel procesador. Esto será así si la interrupción es la generada por el reloj delsistema y se detecta que se ha consumido la porción de tiempo asignada (en un

Rolito

Note

hasta aqui lei

��

�� '


�� *�� .�!�� 2 �� 3

��

��%%:.:-:�:%�*�*$�.:

��$�"",��8�

��H��-�%��")��*)

� �� I*

-��/��

H�� !��

* �� 5��

�� -��H��

��* ! �� !�*��

�� !�� 4��2� �� 3

7��!�� $ ��9

.��J��!��

�%:��H��:-)"

��

��

��( ��

sistema de tiempo compartido); o bien la interrupción la ha generado algúndispositivo de E/S indicando el fin de una operación previamente solicitada, con loque el proceso que la había requerido sale de su situación de espera y pasa alestado de Preparado. En un entorno de planificación de CPU por prioridades, si esteproceso que acaba de pasar a Preparado tiene mayor prioridad que el que está enEjecución, se le quita a éste último el procesador para asignárselo al proceso demayor prioridad.

Por último, el motivo trivial de pérdida de procesador se debe a que el proceso enEjecución llega a su fin. Detectado esto, el sistema operativo asigna la CPU a algúnproceso preparado.

Si un proceso pierde el control de la CPU ¡habrá que asignárselo a otro proceso!Efectivamente, y hay que realizarlo en dos pasos:

1º Seleccionar el siguiente proceso2º Realizar el cambio de contexto

De realizar el primer paso se encarga el ��0�� (o ��), que utilizando lapolítica establecida de planificación a corto plazo selecciona un proceso de la colade Preparados. Esta política de ��0��1��establece la asignaciónde la CPU a uno de los procesos preparados, mientras que la política de��0��1� se utiliza para elegir uno de los trabajos que están en eldisco duro esperando para ser cargados en memoria y comenzar su ejecución.

Una vez conocido el identificador del proceso que va a apropiarse de la CPU, hayque cederle el control del procesador, pero no antes de realizar el cambio decontexto. Para esto, se da control al ��, que es la parte del sistemaoperativo que se encarga de terminar de salvar el contexto del programa queabandona la CPU (o perderlo definitivamente si se debe a una terminación delproceso) y establecer el contexto del proceso seleccionado. De hecho, el último delos pasos de que consta el cambio completo del contexto, consiste en restaurar elContador de Programa del proceso elegido. Una vez que el registro Contador dePrograma es restaurado, la siguiente instrucción que se ejecuta es ya unainstrucción del proceso seleccionado.

La Figura 12 muestra una secuencia completa de dos cambios de contexto. Elprimero se debe a la pérdida de la CPU del Proceso A en favor de Proceso B,mientras que en el segundo cambio, el Proceso A recupera el procesador. Veamoscon cierto detalle un posible algoritmo que realiza este cambio de contexto. Noobstante, este grado de detalle dista bastante de ser completo, ya que para ellohabría que particularizar las operaciones el cambio de contexto para un procesadorconcreto y un conjunto dado de Llamadas al Sistema.

• Llamada al sistema o interrupción de un dispositivo. En cualquier caso, estoimplica automáticamente una copia del REGISTRO DE ESTADO y delCONTADOR DE PROGRAMA a la Pila del proceso en ejecución, al quellamaremos Proceso A.

• Se comienza a realizar el servicio solicitado o el tratamiento de la interrupción.

��

�� )


�� !��!��0��

* ! �� !�*�� * �K��!��!�� !��0��

�)��L�,%*)"�* �L�,%*)"�*

��H�H) ��"��"� ��!��/� !��

H��-��%:�")-:@:-��$��.�)

-- Actualizar el final de la cola Preparados.

Procesos(Preparados.Ultimo).Siguiente := En_Ejecución;

Preparados.Ultimo := En_Ejecución;

-- Seleccionar un proceso.

Proceso_Seleccionado := Preparados.Primero;

-- Actualizar el principio de la cola Preparados.

Preparados.Primero := Procesos(Preparados.Primero).Siguiente;

-- Cambiar el contexto del procesador.

Dispatcher;

7 9

��

��* ��

• Se salvan todos los registros del procesador en la Pila del proceso actualmenteen ejecución (el A). A excepción del REGISTRO DE ESTADO (RE), CONTADORDE PROGRAMA (CP) y PUNTERO DE PILA (PP).

• Tras decidir que el proceso en ejecución debe abandonar la CPU, el Planificadorelige el proceso que pasará a Ejecución, al que nos referiremos como ProcesoB.

• Se llama al !�� y comienza el cambio de contexto. Se producen lassiguientes acciones:

1. El Puntero de Pila del proceso A se guarda en su Descriptor de Proceso.

2. Se carga el Puntero de Pila a partir del PP guardado en el Descriptor delProceso B. Ahora la Pila de trabajo es la del proceso B

3. Se cargan todos los registros generales del procesador a partir de los datoscontenidos en la Pila, a excepción del RE, el CP y el PP.

4. El valor que queda en la cima de la Pila es la dirección de vuelta del últimopunto en el que se llamó al Dispatcher cuando el proceso B perdió el control dela CPU.

5. Se actualiza la variable En_Ejecución con Proceso_Seleccionado.

6. El Dispatcher termina. Al ejecutar la instrucción de RETORNO DE SUBRUTINA,se devuelve el control al punto en el que se había llamado al Dispatcher paraque el proceso B perdiese el control del procesador.

7. El sistema operativo termina de realizar el servicio que el Proceso B le habíasolicitado, por lo que ejecuta la instrucción máquina RETORNO DEINTERRUPCIÓN. Esta instrucción origina que se cargue el REGISTRO DEESTADO y el CONTADOR DE PROGRAMA con los dos datos que se sacan de lacima de la Pila.

8. Con el nuevo CONTADOR DE PROGRAMA, la instrucción que se ejecuta es lasiguiente al punto en el que el proceso B realizó una Llamada al Sistema (loque supuso su paso a Espera).

Ya hemos visto que el cambio de CPU de un proceso a otro requiere una serie deacciones que se encargan de realizarlas el Planificador y el !��. Pues bien,estas acciones se ejecutan en un tiempo que, desde luego, no es nulo. La eleccióndel proceso a ejecutar suele ser muy simple y no supone una pérdida de tiempoconsiderable; pero el cambio de contexto sí puede acarrear una gran cantidad deinstrucciones, incluidas operaciones de E/S si los contextos de memoria de losprocesos que intervienen hay que salvarlos y traerlos, respectivamente, del discoduro, cosa que suele realizarse en los actuales sistemas con Memoria Virtual.

No es deseable, en absoluto, que el tiempo dedicado al cambio de proceso seaconsiderable. Pensemos en un caso exagerado : si el 20% de las instruccionesejecutadas en la CPU son las dedicadas a realizar el cambio de ejecución de dosprocesos, esto quiere decir que a las instrucciones de los programas del usuario

��

��

6 LV WHP D V �2 S H UD W LY R V �, * H V W Ly Q �G H �3 UR F H VR V ��

& DP E LR �G H �3 U R F H V R � !��

� � � !�� !�� !�� !� �� , �� !�� * ! � � � � � � � �� !�� !� � 0 � � � � �

* � � �: � � � � � �C � � � � � �* � � 1

$ �� !� � � � !�� 4 � � �� !� � � � � � �: � � � � !� � � � � ��

� � � � ! � � � !�� !� �� !�� # � ��

" � � � � � � � �!� � �" � � � � � � �� !� �� , �� !� �� !� �2 4 � � � � �� 5 �" � 3

" $ �

�

�

�

�+ �" � � � � � � �" � � � � � ��

+ �" � � � � � � ��

solamente se le dedica el 80% del tiempo de CPU, mientras que, claramente, lo másdeseable es que se acercara lo más posible al 100%.

De la observación anterior se deduce que conviene:- minimizar el número de cambios de proceso,- o minimizar las operaciones del cambio de contexto.

Esta conclusión la tendremos presente en los siguientes apartados, en los quevamos a tratar más a fondo las acciones concretas del Dispatcher y algunas de laspolíticas más comunes de planificación de CPU.

��

��


*�� .�!�� ")��*)

:*�*$�.:)��":$��)

�")��*)C

��

��

��

��

��

��

��

*�!��" ��?:

* ! ��

��" ��?C

��

*�!��" ��?C

* ! ��

��" ��?:

��

int. o Sys_call

int. o Sys_call

��

��

��!�� $��

Veamos ahora una situación, a primera vista comprometida, que se puede dar en unsistema multiproceso. Sabemos que cuando un proceso cede voluntariamente elcontrol de la CPU, el Planificador tiene que elegir otro proceso de usuario que estépreparado, pero

¡Qué pasa si no hay ningún proceso Preparado?

Si no hay ningún proceso que quiera ejecutar instrucciones ¡qué hace la CPU?Esta situación no solamente es perfectamente posible, sino que se da con muchafrecuencia. En un sistema con cinco usuarios ¿qué impide que en un instantedeterminado cuatro de los procesos estén esperando una respuesta del disco duro,la llegada de un carácter por una línea de comunicaciones, o que llegue una horadeterminada? La respuesta es: nada. Pues si en este momento el proceso delquinto usuario también realiza una petición a un dispositivo de E/S, también pasa aEspera. En este momento el Planificador tendría que seleccionar un proceso de lacola de Preparados, para darle el control, pero ¡ya no hay más procesos! ¿qué va ahacer la CPU mientras todos los procesos están en Espera?

Hemos mencionado solamente los procesos de usuario, pero también hay procesosdel sistema operativo que pueden estar realizando servicios que se les hayasolicitado con anterioridad, por ejemplo, imprimiendo un fichero. De cualquier forma,tampoco hay nada que impida que en un momento dado no haya ningún procesocon necesidad de ejecutar instrucciones.

Para estos casos, en todos los sistemas suele haber un proceso del sistemadenominado ��. Este proceso consta de un bucle infinito ejecutandoun algoritmo muy sencillo (puede ser incluso la instrucción "�#��) en el queno figura ninguna instrucción que pueda generar un paso a Espera. El procesoocioso puede estar continuamente realizando estudios estadísticos de utilización delsistema, calculando decimales del numero π, o cualquier trabajo infinito de la menorprioridad. De esta forma, siempre tendremos un proceso Activo.

Diremos que la CPU está ociosa cuando esté ejecutando el Proceso Ocioso.

Los procesadores suelen disponer de la instrucción HALT (o WAIT), la cual haceque se detenga la ejecución de instrucciones en la CPU, es decir, se deja de extraerinstrucciones de la memoria, y la CPU pasa al estado !��, en el quepermanece hasta que se produce una interrupción, pues en ese momento elprocesador la atiende y comienza a ejecutar las instrucciones de su rutina detratamiento.

��%� ��&�� Habiendo visto el ciclo de vida de los procesos, sabemos que un proceso que seestá ejecutando, eventualmente, por diversos motivos que se han comentado,abandona la posesión del procesador voluntaria o involuntariamente, por lo que hay

��

��

que cederle la CPU a un proceso que sea lógicamente ejecutable, es decir, que estéPreparado. Si hay más de un proceso Preparado, el sistema operativo debe decidircuál de ellos se ejecutará primero. La parte del sistema operativo que lecorresponde tomar tal decisión es el ��0��, que seleccionará un procesobasado en una política o algoritmo de planificación.

El estado de Preparado se implementa como una cola de procesos dispuestos aejecutar instrucciones con ayuda de la CPU. Ahora bien, debemos a aclarar queesta cola no tiene por que ser una cola FIFO (Primero en Entrar, Primero en Salir),también podría ser una cola ordenada por prioridades, un árbol o, simplemente, unalista desordenada. El Planificador debe seleccionar uno de los procesos de la lista,pero no basándose necesariamente en la propia estructura de la lista. La estructurade la lista únicamente debe ayudar al Planificador a aplicar el algoritmo deplanificación.

��%��

Antes de ver algoritmos concretos de planificación debemos recordar, que laelección que el Planificador va a realizar debe hacerse persiguiendo “el bien delsistema”, pues es uno de los cometidos del sistema operativo. No obstante, distintaspolíticas de planificación tienen diferentes propiedades, y favorecen más a un tipode procesos que a otros. Antes de elegir el algoritmo a utilizar en una situaciónconcreta, debemos considerar las propiedades de varios algoritmos.Se han sugerido muchos criterios para comparar algoritmos de planificación deCPU. Decidir las características que se van a utilizar en la comparación esfundamental para la elección del algoritmo más apropiado. Veamos los criterios decomparación más comúnmente utilizados:

• 2��. Cada proceso debe conseguir su porción correspondiente de CPU enun tiempo finito.

• ,0��. Se debe intentar mantener la CPU ocupada el mayor tiempo posible.Al decir “ocupada” queremos decir ejecutando cualquier proceso que no sea elProceso Ocioso. En un sistema real, el porcentaje de utilización de CPU sueleestar en el rango 40-90%. Una utilización mayor del 90% significaría que elPlanificador siempre encuentra procesos en la cola Preparados, o sea, que dichacola suele contener un número considerable de procesos. En un sistemainteractivo, esto puede suponer que los usuarios quizás se están impacientandopor obtener las respuestas.

• .��3�� (��). Desde el punto de vista de un proceso, elcriterio más importante es cuánto tiempo se va a necesitar para ejecutarsecompletamente. El Tiempo de Retorno es la suma de los periodos que se pasanesperando a cargarse en memoria, esperando en la cola de Preparados,ejecutándose en la CPU, y esperando por operaciones de E/S. Así pues, se debeminimizar el tiempo de retorno de un proceso. Afecta principalmente a losprocesos ��.

• .��,�� El algoritmo de planificación de CPU no afecta a la cantidadde tiempo que un proceso se pasa realizando operaciones de E/S, solamente

��

�� "


*�� .�!�� !��0��

�!��!��0�� * ! �� !�� #� ��

��5�- �� * �K��!��C�� :!��

@�� $ �� " ��

�0� �� $ ��

$ �� " �� " ��

��!�� !��0��

��2 ��63

��!��5� �� !2 3

��!�� %! ��

��!�.��/��

��

��$ ��2"��"� �3

��

��.K!��! ��!��

��.K!��! ��!��" �!� ��

��

��& ��

afecta al tiempo que un proceso se pasa en la cola Preparados. El Tiempo deEspera es la suma de todos los momentos que un proceso pasa en la cola de losprocesos preparados.

• .��3��. En un sistema interactivo, el Tiempo de Retorno puedeno ser un buen criterio. A menudo, un proceso puede producir algunos resultadosal principio, y puede continuar calculando nuevos resultados mientras losanteriores se le muestran al usuario. Así, tenemos que otra medida es el tiempoque transcurre desde que se le hace una petición al sistema hasta que empieza aresponder, sin tener en cuenta el tiempo que se tarda en mostrar la respuestacompleta.

• 3��. Se debe maximizar el número de trabajos procesados por unidadde tiempo.

Es deseable maximizar la utilización de la CPU y minimizar los tiempos de retorno,de espera y de respuesta, todo ello con la mayor justicia para todos los procesos.Sin embargo, es fácil observar que algunos de estos criterios son contradictorios.Por ejemplo, para que en los procesos interactivos el tiempo de respuesta seabueno, se puede impedir que se ejecuten procesos batch por el día, reservandopara éstos las horas nocturnas en las que no suele haber usuarios en los terminales.Esto no les sentará muy bien a los usuarios que han encargado trabajos en batch,pues ven que el tiempo de retorno se incrementa. Como en otros aspectos de lavida, lo que beneficia a unos, perjudica a otros; así que, en cualquier caso, no habráque olvidarse nunca del criterio que hace referencia a la justicia.

En pro de la justicia, en la mayoría de los casos se suelen optimizar los valoresmedios, no obstante, bajo algunas circunstancias, es deseable optimizar losmínimos o los máximos valores, en lugar de la media. Por ejemplo, para garantizarque todos los usuarios obtienen un buen servicio, lo que se desea es minimizar eltiempo máximo de respuesta.

También se ha sugerido que, en los sistemas interactivos, es más importanteminimizar la varianza en el tiempo de respuesta, que minimizar su valor medio. Espreferible un sistema con un tiempo de respuesta razonable y predecible, que otroque aunque por término medio resulte más rápido, sea altamente variable.

��%�� '��&��

En los diagramas de estados de los procesos, vimos que cuando un proceso enEjecución abandona tal estado pasa a Espera o a Preparado, dependiendo si deja elprocesador voluntaria o involuntariamente. Si los procesos de un sistema nuncadejan la CPU de forma involuntaria, se dice que la política de planificación de CPUes ��!�� o no expropiativa (��). Por el contrario, sipueden perder la posesión del procesador sin solicitarlo, nos encontramos con unaplanificación �!�� o expropiativa (��).

��

�� '

Las políticas no expulsoras suelen aplicarse en sistemas batch o en pequeñosentornos monousuario, como el sistema operativo MS-DOS o el entornoWindows-95/98, ambos de Microsoft. Algunos algoritmos que se emplean en estaplanificación son �� $��, ��%��, y ��.

Por otra parte, los algoritmos expropiativos se utilizan en sistemas de controlindustrial y entornos multiusuario. Los algoritmos más utilizados aquí incluyen&��$&��, ��, de �'�� y de �'��(como es el caso de Unix y Windows/NT).

Veamos a continuación algunos comentarios sobre estos algoritmos.

• ��+��Este algoritmo, cuyo nombre abreviaremos con FCFS ((��$�(��)��),es, con mucho, el algoritmo más simple. Según este esquema, el primer procesoque reclama la CPU, es el primero en conseguirla. En cuanto a laimplementación, no merece la pena dar muchas explicaciones, pues basta conmantener, por ejemplo, una cola FIFO de los descriptores de los procesos quevan solicitando la CPU.

El tiempo medio de espera es muy variable y raramente es el mínimo. En elgráfico superior de la Figura 14 se muestra un caso que según ese orden dellegada, resulta un tiempo medio de espera de 17 ms. En cambio, si el orden dellegada de los trabajos o procesos hubiera sido T2, T3, T1, se puede comprobarque habría dado lugar a un tiempo medio de espera de 3 ms.

Otro problema que puede aparecer al aplicar este algoritmo se da en el siguienteescenario. Supongamos un sistema con esta política FCFS en el que hay unproceso (Proceso-CPU) que consume grandes porciones de CPU y realiza pocasoperaciones de E/S. Por el contrario, hay muchos otros procesos con un ciclo enel que realizan frecuentes operaciones de E/S y ejecutan muy pocasinstrucciones sobre la CPU (Procesos-E/S). Mientras el Proceso-CPU se ejecuta,los Procesos-E/S acabarán sus operaciones con los dispositivos periféricos ypasarán a la cola Preparados, quedando libres los dispositivos de E/S. En algúnmomento, el Proceso-CPU acabará por realizar una operación de E/S y pasará aEspera. Los Procesos-E/S, que necesitan poca CPU se ejecutan rápidamente yvuelven a las colas de espera de los periféricos de E/S. La CPU queda ociosa. ElProceso-CPU finaliza la operación de E/S y vuelve a tomar control delprocesador. Otra vez, los Procesos-E/S terminarán sus operaciones de E/S ypasarán a Preparados, esperando todos a que el Proceso-CPU realice otraoperación de E/S. Cuando se produce esta situación, en la que muchos procesosque necesitan poca CPU esperan por uno que consume mucho tiempo deprocesador, se denomina �*�� . Este efecto provoca una menorutilización de la CPU y de los periféricos de la que se podría conseguir si seconcediese la posesión de la CPU a los procesos que requieren poco tiempo deprocesador, en lugar de cedérselo a un proceso que va a hacer esperar muchotiempo a muchos procesos.

��

��( ��


*�� .�!�� !�� !��0��!�� %! ��/�� * ��

��! �

��$ �� ! ��"�� !��

��- �� 6��!�� I*

�!�.��/� !�� )0� � �� !��

$�� $ �� ' (B( == =

$�� ' �$��( �$��=

$ �� M�2N&(B&(D3�I�=�M�'D

N (B (D =N

$�� $ �� ' (B( == =

$��( ��$��= �$�� '

$ �� M�2N&=&A3�I�=�M�=N = A =N

��!� ��!�� !�� !�� .��!J�� !��!��0��!��!�J�

��

�� )

• ,��4��Este algoritmo, también conocido como SJF ()��+��(��), concede la CPUal proceso que durante menos tiempo necesita la CPU de forma ininterrumpida.Debe quedar claro que se selecciona el que menor porción de tiempo de CPUnecesita en el momento de hacer la elección, no aquel cuyo tiempo total de CPUes el menor de todos. Si dos procesos necesitan el procesador durante el mismotiempo, se elige uno mediante FCFS.

En la parte inferior de la Figura 14 tenemos la aplicación de este algoritmo anuestro ejemplo. Como se puede ver, consigue el menor tiempo de esperaposible. Poniendo a un proceso corto por delante de uno largo, se decrementa eltiempo de espera del corto más de lo que se incrementa el del largo.Consecuentemente, el tiempo medio decrece.

Este algoritmo, probablemente el óptimo, se comporta bien en la planificación alargo plazo de los procesos batch, en los que se conocen los requisitos de tiempototal de CPU indicados por el usuario; pero en la planificación de la CPU sepresenta el problema de que en el momento en que hay que asignar la CPU, nohay forma de conocer a priori la porción de tiempo que necesita cada proceso,por lo que es difícilmente implementable. Se puede intentar una aproximación alSJF puro, haciendo una estimación de la porción necesaria basándose enestadísticas de ejecuciones anteriores.

• �� Este algoritmo está especialmente diseñado para los sistemas multiusuario detiempo compartido. Es similar al FCFS, pero se le añade la expropiación de laCPU cuando la posesión continuada de ésta sobrepasa un tiempo preestablecido(��), que suele ser del orden de 10 a 100 milisegundos.

La implementación de este algoritmo se realiza con una cola FIFO para losprocesos Preparados. Los nuevos procesos se añaden al final de la cola. Cuandoel planificador tiene que seleccionar un proceso, elige el primero de la cola,establece una temporización correspondiente a la porción de tiempo, y le cede elcontrol. Ahora pueden ocurrir dos cosas:

1ª) El proceso termina o realiza una operación de E/S antes de que se acabe suporción de tiempo, en cuyo caso cede la CPU voluntariamente, pasa a esperay el planificador selecciona el siguiente proceso de la cola Preparados.

2ª) El proceso se ejecuta hasta dar lugar a que venza la temporizaciónestablecida. En este caso, el dispositivo temporizador genera una interrupciónque captura el sistema operativo, dando lugar a que se le expropie la CPU alproceso en ejecución, que pasa al final de la cola Preparados, y a que elplanificador seleccione al primer proceso de la cola para pasar a ejecución.

Ya habíamos comentado anteriormente la falta de eficiencia que pueden causarlos cambios continuos del proceso en ejecución. En el caso de que la política deplanificación del procesador sea por Prioridades de los procesos, se nos haceimposible establecer la frecuencia de los cambios, pues vendrá impuesta por los

��

��* ��


*�� .�!�� !�� !��0��$ ��2��3

�� '

�� (

�� =

��

��

$�� $ �� ' (B( == =

N A G '( 'D (( (D =N

$��' ��$��(�$��= �$��' �$��' $��' ��$��'

�!�" �� !�*�� - � �� !�� $ ��

� #� O� ;��

*�!��6�5�� 4�� H�H*7 9

��

��

fenómenos externos que afectan a los procesos correspondientes. En cambio, sila planificación es por Tiempo Compartido, sí está en nuestra mano establecerporciones de tiempo de CPU muy grandes, tal que en una unidad de tiempo seproduzcan muy pocos cambios del proceso en ejecución. Sin embargo, esto noresulta tan fácil de decidir, pues si la porción de tiempo se hace muy grande, elaprovechamiento de la CPU por parte del usuario se ve altamente incrementada,pero, por contra, también ocurrirá que los usuarios de los terminales notarán que“se les tarda mucho en atender”, pues se ha degenerado en una política FCFS.Por el contrario, si la porción se hace muy pequeña, se les atiende enseguida,pero durante muy poco tiempo, con la consiguiente degradación en elaprovechamiento de la CPU por parte del usuario.

• ��Uno de los factores a tener en cuenta en la planificación de los procesos es lajusticia, pero justicia no siempre significa un reparto a partes iguales, sino laasignación más conveniente que aconsejen las circunstancias. Así, por ejemplo,tenemos que en un programa de control y supervisión de una central nuclear,compuesto por diversos procesos, no se debe esperar que todos los procesoscuenten inexcusablemente con la misma porción de tiempo de CPU, ni según unturno circular. Evidentemente, no es tan importante el proceso interactivo que seencarga de mostrar a los visitantes un vídeo de la historia de la central yresponder a sus preguntas, como los procesos encargados de supervisar losniveles de presión, temperatura, radioactividad, etc., y que en caso de que sesobrepasen los límites de seguridad activan las válvulas y avisoscorrespondientes.

Los criterios para establecer las prioridades pueden ser variados: por razonesfísicas, como en el caso de los sistemas de tiempo real, por rangos o categoríasde los usuarios (sistemas multiusuarios), por factores políticos, etc. En sistemasmultiusuario, es muy común tener prioridades por grupos de trabajo odepartamentos, y a los procesos de la misma prioridad aplicarles una políticareparto de tiempo compartido.

Este algoritmo puede ser �� o ��. Cuando un proceso llega a lacola Preparados, se compara su prioridad con la del proceso en ejecución. Conun algoritmo expulsor por prioridades, si la prioridad del recién llegado es mayorque la del proceso en ejecución, se le expropia la CPU a este último en favor delrecién llegado. Si la política es no expulsora, simplemente se coloca al nuevoproceso a la cabeza de la cola. El algoritmo SJF es un caso particular de estealgoritmo con política no expulsora, donde la prioridad es la inversa del tiemporequerido de CPU.

Un problema que se puede dar con este tipo de algoritmos de planificación es elbloqueo indefinido o ��. Un proceso que está preparado, pero que noadquiere la CPU, se puede decir que está bloqueado en espera de procesador.Pues bien, con un algoritmo por prioridades puede darse el caso de dejar a unproceso de baja prioridad esperando indefinidamente por el procesador sisiempre hay algún proceso de alta prioridad que puede “colarse”. (Existe el rumorde que cuando en 1973 se paro el sistema IBM 7094 del Instituto Tecnológico de

��

��

Massachusetts para sustituirlo por otro, se encontró un proceso que llevaba enespera de CPU desde que se había creado en 1967 y todavía no había podidollegar a ejecutarse por primera vez.)

Una primera aproximación al problema de la inanición en sistemas conprioridades, puede consistir en repartir la CPU entre los procesos de la mismaprioridad, es decir, tener una política de tiempo compartido dentro de cada colade prioridad.

Una técnica más refinada es la del ��+��. Con esta sistema, laprioridad de los procesos preparados se incrementa gradualmente a medida queesperan en la cola Preparados, donde permanecen hasta alcanzar,inevitablemente, la prioridad necesaria para conseguir la CPU.

6 LV WHP D V �2 S H UD W LY R V �, * H V W Ly Q �G H �3 UR F H VR V ��

6 LV W HP D V �0 X OW LS U R F H V R � �� !�� !� � 0 � � � �

� � � � � � � � �2 4 � � !� � � � � 3

� �% � � �� $ � � ��

$ �� !�� !�� !� �� , �2 �� 3 !�� . � 5 � � ��

: � % � � : � �) � � *

; �� 2� � � � � � �� 3

$ � � � �" � !

� � � � � � �� !�� 7 9

* ) %, � �) � � * ��

�� P� � � � � � � � � Q

��

��

• %5��Existe otro tipo de algoritmos para situaciones en las que los procesos estánclaramente clasificados en diferentes grupos. Por ejemplo, una división muycomún es la que se hace entre procesos interactivos de primer plano (*��)y los procesos batch que suelen ejecutarse en un segundo plano (��).Estos dos tipos de procesos tiene distintos requisitos en sus tiempos derespuesta, por lo que podrían tener distintos algoritmos de planificación cada uno.Además, los procesos interactivos podrían tener mayor prioridad que los seejecutan en un segundo plano.

Para esto, la cola Preparados podría estar dividida en varias colas separadas,una por cada tipo de proceso. Cada proceso siempre se encola en su colacorrespondiente. Así nos encontramos con que para elegir la cola de la que se vaa sacar un proceso se utiliza una política, mientras que para seleccionar quéproceso se va a sacar de la cola elegida, se utiliza un algoritmo distinto. Tambiénpuede ocurrir que en dos colas distintas se utilice la misma política deplanificación, por ejemplo, tiempo compartido, pero que la porción de tiempo seadistinta en una cola que en otra.

• %5��Una mezcla de las técnicas de envejecimiento y de las múltiples colas, resulta enlas múltiples colas realimentadas.

Las distintas colas pueden tener políticas de tiempo compartido, pero las másprioritarias poseen una mayor porción de tiempo. Cuando un proceso lleva muchotiempo en una cola de poca prioridad, se le pasa a otra cola de mayor prioridad,consiguiendo así mayores porciones de tiempo.

��%�!� ��&��

Hasta ahora hemos tratado con algoritmos de asignación de CPU en sistemas conun solo procesador. Si se dispone de múltiples procesadores, la planificación sevuelve bastante más compleja.

Al igual que en el caso de los sistemas monoprocesador, no existe la soluciónóptima, sino que ésta depende de varios factores, y siempre hay unos procesosbeneficiados y otros perjudicados. Vamos a tratar simplemente algunos conceptosgenerales sobre la planificación de múltiples CPU’s. Un estudio en profundidad deeste apartado puede encontrarse en literatura sobre arquitecturas avanzadas yparalelas.

Cuando todos los procesadores de un sistema tienen la misma funcionalidad(�� 6��7��), cualquier procesador disponible puede utilizarse paraejecutar un proceso preparado. Pero si los procesadores son distintos (��6��7��), sólo los programas compilados para un procesador determinadopueden ejecutarse en ese procesador. Este es el caso de los sistemas distribuidos.

��

��


�!��0�� .K!��! �� %��

-�H�"��$�*2*�� < � �� 3

�;,:%�*2*�� <�� 3

�� !��5��

�!��0��

�� !�� #� �!

��

��!��

��7�� #�! ��9

- �6� ��K��!��

:��!��0��

,�� ! � �� !��!�

7��,�-:-)�9

,�� 6�� !��0��5�� !��

�� !��

��

�� "

También puede haber algunas limitaciones en la asignación de CPU en los sistemashomogéneos, como es el caso de un programa que haga uso de un dispositivoespecial de E/S conectado a un bus privado de un procesador concreto, en cuyocaso solamente se le puede asignar tal CPU para ejecutarse.

En el caso de los sistemas heterogéneos, cada procesador dispone de su propiacola Preparados y de su planificación particular, y cada proceso entra en la cola delprocesador que le corresponde.

En los sistemas homogéneos se podrían tener también varias colas, una porprocesador, pero esto podría dar lugar a una carga desequilibrada, con algunascolas con muchos procesos, y otras colas vacías con su CPU ociosa. Para evitaresto, suele ser mejor disponer de una única cola de procesos preparados. Hay dosmétodos para sacar los procesos de la cola.

• Uno es mediante ��*��, en el que cada procesador que queda libresaca un proceso de la cola. En este método hay que controlar la posibilidad deque dos procesadores intenten sacar simultáneamente al mismo proceso de lacola.

• El otro sistema es dedicando un procesador a trabajar como planificador, siendoél el único que saca procesos de la cola y los asigna entre los procesadores,evitando así los conflictos del método anterior.

��%�%� (��&��)�*��$�� +��

Aunque los conceptos de sistemas operativos pueden estudiarse o considerarse entérminos puramente teóricos, resulta conveniente observar cómo se hanimplementado algunos sistemas operativos comerciales. Así, ahora vamos acomentar, aunque solo sea superficialmente, algunas de las decisiones de diseñoque se han tomado sobre la planificación de la CPU en Unix, Linux y Windows NT.

8��!La primera versión de Unix se desarrolló en 1969 por Ken Thompson en losLaboratorios Bell. Muchas versiones y emulaciones se han hecho desde entonces.

Una de las últimas versiones de Unix es la )��,-��., aparecida en 1989.No obstante, muchos otros fabricantes también han desarrollado sus propiasversiones de este popular sistema operativo. Así tenemos las versiones de IBM(AIX), HP (HP-UX), Sun (Sun OS y Solaris), DEC (Ultrix) y algunas más. También sehan desarrollado versiones para PC’s, como la de Microsoft (Xenix), la de SantaCruz y la de Tanenbaum (Minix), y para las más variadas plataformas, desde elMacintosh de Apple hasta supercomputadores como el Cray II.

Una de las versiones de Unix más populares ha sido la desarrollada en laUniversidad de Berkeley por el Departamento de Defensa norteamericano para

��

��& ��

utilizarlo en instalaciones gubernamentales. Esta versión fue la 4BSD, siendoconcretamente la 4.3BSD (año 1986) una de las que tuvieron más auge deutilización.

También merece especial mención Linux, que desde mediados de los años 90 hatenido una espectacular difusión, y al que le trataremos en un apartado particular.

Ahora vamos a comentar aquí la política de planificación del procesador utilizada porUnix en su versión 4.3BSD.

Ya que se trata de un sistema operativo multiusuario, la planificación de Unix estádiseñada para favorecer a los procesos interactivos, para lo cual utiliza unaplanificación por prioridades, cediendo la CPU en porciones de tiempo al procesomás prioritario. El algoritmo concreto es el de “colas multinivel con realimentación(mediante envejecimiento)”, de tal manera que para procesos con gran carga deCPU el algoritmo de planificación se convierte en ��$��. Veámoslo con ciertodetalle.

Las porciones de tiempo son de 100 ms., por lo que cuando un proceso llega altérmino de su porción sin haber cedido la CPU, se le quita la CPU para cedérsela alproceso preparado con mayor prioridad. Las prioridades, no obstante, sondinámicas, es decir, que la prioridad de un proceso va variando a lo largo de suvida. Aunque las porciones de tiempo son de 100 ms. la reevaluación de lasprioridades se realiza una vez por segundo, para que no suponga una sobrecargaconsiderable. Esto quiere decir que cada segundo se aplica el algoritmo queestablece la prioridad de cada proceso. El algoritmo en cuestión es el siguiente:

M

M

MM��

�� +

−+=

2

)1()(

2

)1(

2

)( −+=

�� MM

M

donde

�M�� Prioridad del proceso � al comienzo del intervalo �. Cuanto menorsea este número, mayor es la prioridad.

��M � Prioridad de base del proceso �.

��M �� = Media ponderada exponencial de la utilización de CPU del proceso �en el intervalo �.

�� = Utilización de CPU del proceso � en el intervalo �.

��M = Factor de ajuste controlado por el usuario.

��

�� '

El propósito de la prioridad base es establecer bandas fijas de prioridades, de talmanera que a los distintos tipos de procesos se les asigna una prioridad basepredeterminada. Las bandas son, en orden de prioridad decreciente, para lossiguientes tipos de procesos:

• Procesos de intercambio a disco• Procesos de dispositivos de E/S por bloques• Procesos de gestión de archivos• Procesos de dispositivos de E/S de caracteres• Procesos de usuario

Esta jerarquía tiende a proporcionar un aprovechamiento más eficiente de losdispositivos de E/S. Obsérvese que dentro de los procesos de usuario, también setiende a penalizar a los procesos que consumen mucha CPU, pues cuanto másprocesador consume un proceso, menor se hace su prioridad, lo cual terminafavoreciendo a los procesos que más utilizan los dispositivos de E/S. Esto tiende aevitar el “efecto convoy” comentado en la planificación FIFO. También debemosobservar que ya que se tiene en cuenta (y se penaliza) el consumo de CPU que harealizado cada proceso en su anterior posesión del procesador, este algoritmotambién se comporta como una aproximación a “el más corto - el primero”, el cual yavimos que ofrece los mejores tiempos medios de espera.

Ya que a todos los procesos de usuario se les asigna la misma prioridad base, paraeste tipo de procesos el algoritmo se comporta como si fuera &��$&�� (aunquecomo ya hemos dicho, favoreciendo a los procesos con poca carga de CPU), noobstante, se puede favorecer en cierta manera a algunos procesos de usuariomediante el comando nice.

Debido a este algoritmo con envejecimiento, resulta muy difícil que un procesopueda apropiarse de forma exclusiva de la CPU evitando así la “inanición” de losprocesos.

9��!Linux es otro sistema operativo “tipo Unix” en el que aunque la compatibilidad conUnix era uno de los objetivos de diseño, tiene algunas particularidades que difierendel Unix estándar, entre ellas la política de planificación de procesos, y dada lapopularidad que ha adquirido en estos últimos años, merece la pena comentarlo.

El desarrollo de Linux comenzó en 1991, cuando el estudiante finlandés LinusTorvalds escribió un pequeño kernel o núcleo para el procesador 80386 de Intel y lopuso a disposición de todo el mundo de forma gratuita a través de Internet. Estenúcleo implementaba un subconjunto de la funcionalidad de Unix, pero fuecreciendo hasta adquirir la funcionalidad completa.

Alrededor del único ��/�� se han construido multitud de programas queconstituyen el �� /��. Alguno de estos programas se ha construido

Prioridad

��

��( ��

expresamente para Linux, mientras que otros se han tomado prestados de otrossistemas o proyectos de colaboración.

Una ��/�� consta de los componentes estándar de un sistema Linux,más un conjunto de herramientas de administración que ayudan a simplificar lainstalación y mantenimiento del sistema. Aunque la primera distribución de Linux fuela de SLS y la de Slackware posiblemente la más popular, hoy día hay numerosasdistribuciones, entre ellas: Red Hat, Debian, Caldera, Craftworks, SuSE, Unifix, etc.No obstante, debe tenerse en cuenta que todas ellas comparten el mismo kernel, ylos paquetes o utilidades que ofrece cada una suelen ser compatibles con lasdemás distribuciones.

En este apartado vamos a centrarnos en los aspectos de planificación del kernel deLinux en su versión 2.0. Aunque este sistema operativo está preparado parasistemas multiprocesador, aquí vamos a comentar únicamente la planificación conun único procesador.

Linux dispone de dos algoritmos de planificación (dos clases de planificación). Unoes el de tiempo compartido, para un reparto justo entre múltiples procesos; el otroestá diseñado para tareas de tiempo real, donde las prioridades son másimportantes que la justicia. Cada proceso puede acogerse a cualquiera de estaspolíticas de planificación, y así consta en su BCP.

Para los procesos de tiempo compartido, se utiliza un algoritmo basado en créditos.Cada proceso dispone de un cierto número de créditos, de tal manera que paraseleccionar la siguiente tarea a ejecutarse, se elige a la que tiene más créditosacumulados. Cada vez que se produce una interrupción de reloj, el proceso enejecución pierde un crédito; cuando su número de créditos llega a cero, pierde laCPU y se selecciona otro proceso.

Cuando no queda ningún proceso preparado con créditos, Linux vuelve a asignarcréditos a todos los procesos del sistema según la regla siguiente:

��

�� +=2

Este algoritmo considera dos factores: la historia del proceso y su prioridad. Semantiene la mitad de los créditos de los que el proceso conserva desde la últimaasignación de créditos, recordando así parte de la historia del comportamiento másreciente del proceso. Los procesos con mucha carga de CPU tienden a gastar suscréditos rápidamente, mientras que los que suelen estar suspendidos en espera deoperaciones de E/S van acumulando créditos a lo largo de la historia, de tal maneraque cuando estén en espera de la CPU tendrán más prioridad para ejecutarse, locual produce un tiempo de respuesta muy rápido para los procesos interactivos.

El factor prioridad en el cálculo de la asignación de créditos permite afinar laprioridad real de los procesos. Al asignar una baja prioridad a algunos procesos en��, automáticamente recibirán menos créditos que los procesos

��

�� )

interactivos, y también recibirán un menor porcentaje de CPU que trabajos similaresa los que se les haya asignado una mayor prioridad.

Gracias a este sistema de prioridades dinámicas, procesos de distintas prioridadespueden competir por el procesador, evitando así el problema de la inanición.

Para tiempo real, Linux implementa los dos algoritmos expulsores o expropiativosrequeridos por POSIX: (0(# y &��&��. Esto quiere decir que la información decada proceso debe indicar si se acoge a planificación de tiempo compartido o detiempo real, y en caso de ser este último, debe especificar si utiliza el algoritmo (0(#o &��&��. Veamos cómo se comporta la planificación con cada uno de estosdos algoritmos de tiempo real.

El algoritmo FIFO es el ya conocido para tiempo real, en el que la CPU siempre sele concede al proceso con mayor prioridad, y no se le quita a no ser que pase apreparado un proceso de mayor prioridad. En cambio, los procesos de la mismaprioridad con planificación &��&��, se reparten la CPU en idénticas porcionesde tiempo por turno rotatorio.

Cuando se le solicita al planificador que elija un proceso para pasar a ejecución,busca en la cola de los preparados, eligiendo siempre a un proceso de tiempo realantes que a los de tiempo compartido.

Cuando finaliza una rodaja de tiempo, se comprueba la política de planificación delproceso en ejecución. Si es de tiempo compartido se decrementa un crédito, y si hallegado a cero, se le quita la CPU, cediéndosela al proceso preparado con máscréditos. Si es ��(0(#-��'�� )�� &�� Robin y no hay más procesos preparados de la misma prioridad,continua la ejecución, pero si hay otros procesos preparados de la misma prioridad,se le quita la CPU, se le envía a la cola de preparados, y se le asigna la CPU alsiguiente proceso preparado de esa prioridad.

Ya que la planificación, en cualquier caso, es expulsora, si un proceso pasa apreparado y es de mayor prioridad que el actual proceso en ejecución, se le asignala CPU inmediatamente al proceso de mayor prioridad.

:��;��<.Este sistema operativo nació como consecuencia de que Microsoft decidió construirun nuevo sistema operativo partiendo de cero y con una Nueva Tecnología, quesoportara las aplicaciones tanto para OS/2 como para POSIX, Windows y MS-DOS.

Hay dos versiones de Windows NT: 1�� (puesto de trabajo para un usuario)y �� (utilizado como servidor para aplicaciones cliente-servidor), sin embargoambas utilizan el mismo núcleo, por lo que las características de planificación quecomentaremos aquí se aplican a las dos versiones.

Aunque Windows NT dispone de un sistema de protección para múltiples usuarios,no debe entenderse como un sistema multiusuario, pues no permite múltiples

��

��* ��

usuarios conectados simultáneamente (aunque sí permita múltiples accesossimultáneos como servidor).

La arquitectura de Windows NT está basada en un �� (como Mach), de talforma que facilita las actualizaciones de partes del sistema operativo sin afectar alresto. Y como es típico en los sistemas basados en ��, dispone deprocesos o tareas y de procesos ligeros o ��. Las notas sobre planificación quevamos a comentar se aplican tanto a los procesos como a los �� de WindowsNT en su versión 4.0

Los objetivos de planificación de Windows NT son diferentes a los de Unix. Ésteestá pensado para dar servicio equitativo y rápido a todos los usuarios del sistema,mientras que Windows NT se diseñó para ser especialmente sensible a lasnecesidades de un único usuario en un entorno muy interactivo o en el papel de unservidor.

El planificador utiliza un esquema de 32 prioridades para determinar el orden deejecución. Las prioridades están divididas en dos clases: la �� (con lasprioridades 0 a 15) y la �� (con las prioridades 16 a 31). Unnúmero más alto indica una mayor prioridad. Cuando se crea un proceso se leasigna una “prioridad base”. Las prioridades de la clase variable se suelen utilizarpara los procesos de usuario, mientras que las de tiempo real se reservan para lasactividades derivadas del servidor.

Se utiliza una cola para cada una de estas prioridades, de tal manera que paraelegir el siguiente proceso que pasa a ejecución, se recorren todas las colas, demayor a menor prioridad hasta que se encuentra un proceso preparado. Si no hayningún proceso preparado, se le cede el control al ��.

La CPU siempre se asigna al proceso de mayor prioridad, aunque las prioridades segestionan de forma diferente en las dos clases. En la clase de tiempo real todos losprocesos mantienen su prioridad base, que no cambia nunca, y la CPU se repartepor turno rotatorio entre todos los procesos de la máxima prioridad que tengaprocesos preparados. En la clase de prioridad variable, la prioridad de un procesoparte de su prioridad base y puede subir o bajar (dentro de un cierto margen) a lolargo de la vida del proceso. Así, por cada nivel de prioridad hay una cola FIFO, peroun proceso puede pasar a la cola de otra prioridad dentro de las de prioridadvariable. La prioridad de un proceso no puede cambiar a la prioridad de otra clasedistinta a la que pertenece.

Cuando a un proceso en ejecución se le acaba su porción de tiempo, si pertenece ala clase de tiempo real y hay más procesos preparados de la misma prioridad, se lequita la CPU y pasa al final de la cola de su prioridad, cediendo la CPU al siguienteproceso de esa cola. Si la prioridad del proceso pertenece a la clase variable, se ledisminuye la prioridad (hasta cierto límite). De esta manera se tiende a limitar el altoconsumo de CPU que realizan los procesos de cálculo (con poca E/S); por otraparte, cuando un proceso que estaba en espera pasa a preparado, se le aumenta suprioridad. Este aumento depende del motivo por el que estaba esperando. Losprocesos que esperan por una interrupción de teclado o de ratón son los que

��

��

consiguen un mayor aumento de prioridad, mientras que los que esperan por laconclusión de una operación con el disco sólo consiguen un ligero aumento. Estaestrategia tiende a ofrecer un buen tiempo de respuesta a los procesos interactivoselevando la prioridad a los procesos que esperan por teclado o ratón, dejando quelos procesos con gran carga de procesador se ejecuten en tiempos muertos ensegundo plano.

Aunque esta planificación expulsora siempre le otorga el procesador al procesopreparado con mayor prioridad, no se puede decir que Windows NT sea un sistemaoperativo de tiempo real estricto, pues no garantiza el tiempo mínimo que se tardaen darle control a un proceso de alta prioridad que pasa a preparado.

��0��%��Cuando Windows NT se ejecuta con un único procesador, el proceso preparado demayor prioridad siempre está en ejecución, y si hay más de un proceso con la mayorprioridad, la CPU se reparte por turno rotatorio entre todos los procesos preparadosde esa prioridad.

En un sistema multiprocesador con " procesadores, siempre se mantiene enejecución a los "$2 procesos de mayor prioridad, ejecutándose de manera exclusivaen los "$2 procesadores. El resto de los procesos de menor prioridad comparten elúnico procesador que queda.

��

��

��!�� ,�� Normalmente, los procesos que cooperan en la realización de un trabajo,necesitarán durante su ciclo de vida la sincronización o comunicación entre ellos ocon el proceso maestro que les haya creado. Se hace necesario algún sistema decomunicación cuando se requiere el intercambio de información entre dos o másprocesos. Por ejemplo, un proceso puede estar produciendo una serie de datos quesirven a su vez de entrada a otro proceso (como ocurre con el �� “|” de Unix). Enotros casos, como en los momentos en que se accede a estructuras de datoscomunes a varios procesos, se requiere algún mecanismo de sincronización paraque dos procesos no intenten acceder simultáneamente a dicha estructura pararealizar operaciones de lectura/escritura de forma incontrolada.

Así pues, en los siguientes apartados trataremos los problemas que pueden darse yalgunos mecanismos propuestos para comunicación y sincronización entre procesoscooperantes que comparten el mismo espacio lógico de direcciones.

��!�� Como ya hemos dicho anteriormente, un sistema puede estar compuesto demúltiples procesos que se pueden ejecutar en paralelo (simultáneamente) si sedispone de múltiples procesadores. Cuando solamente se dispone de una CPU, elefecto del procesamiento paralelo puede simularse si los procesos se ejecutanturnándose en la posesión del procesador. En otras palabras, el procesador puedecompartirse entre varios procesos. Incluso simulando el procesamiento paralelo,resulta útil ver cada proceso como si tuviera su propio procesador virtual dedicado.

Muchas de las dificultades que surgen en el verdadero procesamiento paralelotambién se producen en el caso simulado. Uno de estos problemas se muestra en elejemplo del programa superior de la Figura 18.

El primer proceso, el #��, es el responsable de observar y contar eventos. Elsegundo proceso, el &��, ocasionalmente imprime informes sobre el númerode eventos observados hasta el momento y seguidamente pone el �� deeventos a cero. Cuando ambos procesos se ejecutan concurrentemente, puedeproducirse la siguiente situación. Supongamos que el reportero acaba de imprimir un10, y antes de que pueda poner el �� a cero se produce la interrupción detiempo y se concede el control de la CPU al #��. Éste, entonces, incrementael �� a 11. A continuación, el &�� vuelve a tomar posesión delprocesador y pone, por fin, el �� a cero, lo cual significa que un evento quedasin ser contabilizado. En general, el &�� puede fallar al informar de cualquiernúmero de eventos, ya que el incremento de la variable �� puede producirseentre la impresión del valor, y su puesta a cero.

En este ejemplo se muestra que los resultados son impredecibles, ya que losprocesos se ejecutan con velocidades relativas igualmente impredecibles. Cuando elresultado de un cálculo depende de las velocidades relativas de los procesos, sedice que hay una ��. Las condiciones de carrera se producen

��

��

cuando procesos paralelos comparten datos o recursos, como la variable ��del ejemplo.


*��J�� Cuenta_Eventos;Contador : INTEGER := 0;

�� Observador;��Esperar_Evento;Contador := Contador + 1;

��;�� Observador;

�� Reportero;��Imprimir (Contador);Contador := o;

��;�� Reportero;

��Observador;Reportero;

�� Cuenta_Eventos;

��

process Observador;repeatEsperar_Evento;�� ;Contador := Contador + 1;

�� ;forever;

end Observador;

process Reportero;repeat�� ;Imprimir (Contador);Contador := 0;

�� ;forever;

end Reportero;

* ��

�!�� !�� ! ��

�*)%,��8�

��4�!��.��

2" ��3

��

��

��!�� -�*�� '��¿Cómo evitar las condiciones de carrera? La clave para evitar problemas en lassituaciones en que se comparten objetos o recursos es encontrar algún modo deprohibir que haya más de un proceso leyendo o escribiendo el dato compartido almismo tiempo. En otras palabras, lo que se necesita es �!��, es decir,asegurarse de que si un proceso está accediendo a un dato compartido, el otro o losotros procesos estarán imposibilitados para poder hacerlo también.

El problema de nuestro ejemplo es que el proceso #�� puede acceder al�� (lo incrementa) antes de que el &�� haya acabado de realizar lasoperaciones con la variable (le faltaba ponerla a cero), o sea, se accede a la variableantes de que el proceso que la está modificando la deje en un ��.Y este problema se produce porque las operaciones de acceso a la variablecompartida no son indivisibles en su ejecución, es decir, porque no son �� oininterrumpibles.

En la vida de un proceso, parte del tiempo está ocupado con cálculos internos y otrotipo de cosas que no conducen a una condición de carrera. Pero en otras ocasiones,el proceso accede a variables o ficheros compartidos que sí puede conducir a lacondición de carrera. La parte del programa en la que se accede a memoriacompartida se denomina ��=��. Si nos las pudiéramos apañar para que dosprocesos no estuvieran al mismo tiempo en su región crítica, evitaríamos lascondiciones de carrera.

��!�!� ��En la parte inferior de la Figura 18 tenemos nuestro ejemplo transformado deacuerdo a la premisa del acceso a la región crítica. En este programa transformadose muestra una solución abstracta al problema de la exclusión mutua. Podemos verque la región crítica de cada proceso está encerrada entre sendas sentencias deentrada y salida de la región (��3&� y )��3&�). Estaría bien que estasprimitivas de acceso a la región crítica se comportasen como “porteros”, tal que si unproceso intentara entrar en la región crítica ocupada por otro proceso, el primeroquedara bloqueado por el portero hasta que el otro proceso saliese de ella.

��!�!��

Aunque con la exclusión mutua se evitan las condiciones de carrera, no es condiciónsuficiente para que una serie de procesos paralelos cooperen correcta yeficientemente utilizando datos compartidos. Se requieren las siguientes condicionespara obtener una buena solución:

1. Dos procesos no pueden estar al mismo tiempo dentro de la misma regióncrítica.

2. No se deben hacer suposiciones sobre el hardware, es decir, sobre lavelocidad o el número de procesadores que intervienen.

��

�� "

3. No se deben hacer suposiciones sobre las velocidades relativas de losprocesos.

4. Ningún proceso fuera de su región crítica puede bloquear a otros procesos.

5. Ningún proceso deberá esperar eternamente a entrar en su región crítica.

6. No se debe posponer indefinidamente la decisión de cuál es el siguienteproceso que debe entrar.

��!�!��

En este apartado examinaremos, tanto a nivel hardware como software, algunos delos muy diversos métodos de sincronización que existen para resolver el problemade la exclusión mutua. Estos son:

• Inhibición de interrupciones• Espera activa• Semáforos• Monitores

Sobre las versiones originales de algunos de estos mecanismos (semáforos ymonitores) ha habido diversas modificaciones a lo largo de la historia, por ello aquívamos a comentar los conceptos básicos o el cometido fundamental que se buscacon cada uno de ellos, pues su estudio en profundidad sería más propio de un cursode Programación Concurrente. No obstante, en la bibliografía se citan algunos librosen los que se puede encontrar información adicional sobre este tema.

�6�-�� Si se pretende evitar que mientras un proceso está dentro de una región crítica, otroproceso pueda entrar también, la forma más fácil de conseguirlo es evitando que elproceso que se encuentra dentro de la región pierda el control del procesador antesde abandonarla.

Un proceso pierde la posesión de la CPU solamente si realiza una operación de E/So, si debido a una interrupción, se detecta que se le acabó su porción de tiempo oque otro proceso de mayor prioridad pasa a Preparado y seguidamente se apropiade la CPU. Sabido esto, por una parte se puede hacer que un proceso que seencuentra dentro de una región crítica no realice operaciones de E/S, y por otraparte lo que falta por hacer es inhibir la aceptación de interrupciones por parte delprocesador mientras el proceso está dentro de la región. Es decir, que lassentencias Entrar_RC y Salir_RC se podrían corresponder, respectivamente, conlas instrucciones máquina DISABLE (inhibir aceptación de interrupciones) y ENABLE(aceptar interrupciones). Así, una vez que un proceso ha inhibido las interrupciones,puede examinar y actualizar la memoria compartida sin miedo a que otro procesointervenga, pues la secuencia de instrucciones que componen la región crítica seconvierte en una única operación atómica o indivisible.

��

��& ��


*��J�� 4�!��.��" #��! � ��

-�� !�� !��

�� 6�� !�6��R�� 2� !��S�� 3�

�� 6�� !�� !�� !�� !��

��K�� 0� �� !�#� ��

��K��

�� 0�� !�� !� �� !�� #� ��

�

�

�

�

�

�

�:"�)*

*�*$�.:*��6 ��

�� ! +� ��2�� :��3

��* ��0��

��.��

��

��

�� '

La ventaja de este sistema es su simplicidad. Sin embargo, también da lugar avarios inconvenientes:

• La región crítica debe ser corta, pues de lo contrario se podrían perderinterrupciones generadas por los dispositivos de E/S si no se tratan a tiempo.

• Inhibiendo las interrupciones, no solamente se impide que otro procesocooperante que desee entrar en la región crítica pueda continuar su ejecución,sino también a procesos cooperantes que no intentan en la región crítica. Y loque es peor, también se impide que prosigan el resto de los procesos delsistema, que por no ser cooperantes, en ningún momento intentarán acceder alos datos compartidos que se están protegiendo.

• Este método sólo es apropiado para sistemas monoprocesador, pues en unentorno con múltiples CPU’s la prohibición de las interrupciones en unprocesador no afecta a los demás. Una solución a este problema podría ser elcentralizar en un único procesador la gestión de interrupciones, pero nosiempre esto es posible.

• Resulta peligroso darle al usuario un medio para inhibir las interrupciones,pues podría ocurrir que por un error de programación o por cualquier otromotivo no las volviera a permitir, provocando la consiguiente pérdida de lassubsiguientes interrupciones y el acaparamiento en exclusiva de la CPU.

Sin embargo, con frecuencia resulta conveniente para el núcleo del sistemaoperativo la inhibición de interrupciones durante unas pocas instrucciones mientrasactualiza estructuras de datos del sistema, por ejemplo, para actualizar la lista deprocesos Preparados, pues si se dejase en un estado inconsistente, el sistema seiría al traste.

Como conclusión, se puede decir que la inhibición de interrupciones resulta, aveces, una técnica útil o práctica para el núcleo, pero no es apropiada comomecanismo general de exclusión mutua para los procesos de usuario.

Acabamos de ver una solución hardware al problema de la exclusión mutua.Pasemos a tratar algunas soluciones basadas en algoritmos software que tratan deevitar la pérdida de interrupciones y la injusticia de que la protección de una regióncrítica perjudique a todos los procesos del sistema, incluso a aquellos que no tienenninguna relación con la estructura de datos compartida que se quiere proteger.

��

��( ��


�4�!��.�� 6 ��

�")C%�.:*��* ��

��* ��$)-)*�!�� !��,

�� !�� !��

*)%,��8�1�� 0��!��" ��

...

Entrar_RC (RC_Eventos);

...

...

Salir_RC (RC_Eventos);

...

�� 6 ��

�� 0�� !��,

,�!��!��K�! �� !��

��

�� )

,��+��Otra posibilidad de impedir el acceso simultáneo de dos procesos a la región críticaes haciendo que una variable actúe como cerrojo o indicador de si la región críticaestá ocupada o no. Esto se puede hacer con una variable booleana que tome losvalores 0 (libre) y 1 (ocupada). Todos los procesos que deseen acceder a unaregión crítica deben cumplir un protocolo de acceso y salida de la región. Cuando unproceso llegue a la entrada de la región debe consultar el valor de la variable-cerrojo; si el valor es 0, la pone a 1 y entra en la región crítica; si la variable yaestaba a 1, el proceso debe esperar hasta que valga 0.

La idea de este método es similar al acceso al lavabo de un avión de pasajeros. Siel cartel indica /��, entramos, cerramos la puerta, y el cartel pasa a indicar#��. En cambio, si al intentar acceder al lavabo, el cartel indica #��,simplemente esperamos a que quede libre.

Por desgracia, esta idea contiene el mismo problema que nuestro ejemplo de losprocesos Observador y Reportero. Supongamos que un Proceso A lee el cerrojo yve que está a 0. Antes de que pueda ponerlo a 1, pierde el control de la CPU y lotoma otro Proceso B que también quiere entrar en la región crítica. Este últimoconsulta también el valor del cerrojo (que sigue a 0), lo pone a 1 y entra en la región.Antes de salir de la región crítica, finaliza su porción de tiempo y se le devuelve elcontrol al Proceso A, que continúa lo que estaba haciendo, con lo que pone elcerrojo a 1 (otra vez) y entra en la región crítica, creyendo que él es el único queestá dentro, porque ha entrado siguiendo el protocolo de acceso.

Como vemos, el problema se debe a que la consulta del cerrojo y su posteriorpuesta a 1 (ocupado) no se realiza como una acción atómica.

Para solucionar esto han surgido diversos algoritmos, entre ellos, el de la panadería(de Lamport); el algoritmo de Decker (para 2 procesos); el de Dijkstra (para nprocesos); el de Knuth, Eisemberg y McGuire; y el de Peterson. La descripción deestos algoritmos puede encontrarse en cualquiera de los textos indicados en labibliografía.

Se consigue una buena solución con un poco de ayuda hardware. Los procesadoresde propósito general suelen ofrecer la siguiente instrucción máquina (por lo tanto,ininterrumpible en su ejecución):

TAS (Cerrojo, Valor)

Esta instrucción (�� )��) actúa de la siguiente manera. Se lee la variable��, y en función de su valor, se establecen los *�� correspondientes en elRegistro de Estado del procesador. Por último, a dicha variable se le asigna elcontenido del segundo parámetro, ,��. De esta forma se consigue realizar las dosacciones de comprobación y asignación del valor “ocupado” sin ningunainterrupción.

En la implementación de Entrar_RC y Salir_RC con TAS de la Figura 21 sepuede ver que cuando un proceso llega a la entrada de la región crítica, si la

��

��"* ��


�4�!��.�� ! +� �� TST RC_Eventos

BNZ Entrar_RCMOV 1, RC_EventosRET

�� MOV 0, RC_EventosRET

� �� DB 0

��

<�5��:!��#� �!��*�!��T �- UU ��2(�� 3/�-�U��2�� 3T �V��6�� W�.�;�� T �:!�� !�� /�� %��T ��

. ��:5�� !�<X�

Test and Set

Entrar_RC TAS RC_Eventos,1BNZ Entrar_RCRET

Salir_RC MOV 0,RC_EventosRET

��P�� ! �� !�� Q

��7��5��6�5��K!��! ��

�!�;�� ! �� *�!��

�*��":

:�$��:��

��

�� "�

variable-cerrojo RC_EVENTOS no tiene el valor 0, todo lo que tiene que hacer esejecutarse en bucle hasta que la consulta del Registro de Estado indique que lavariable tenía el valor 0. Para anunciar la salida de la región crítica, lo único que hayque hacer es simplemente poner el valor 0 en el cerrojo.

Un problema que se puede producir aquí es que un proceso cumpla con el protocolode entrada a la región crítica y acceda a ella, pero que a la salida se le olvideliberarla. El acceso a la región queda bloqueado indefinidamente.

Hasta ahora este método funciona porque las acciones de �� seejecutan como una sola instrucción ininterrumpible, pero veamos con mayor detallecómo se ejecuta la instrucción TAS. En primer lugar la CPU toma posesión del bus(direcciones, datos y control) para leer el contenido del cerrojo de su posición dememoria. Una vez traído el dato, el procesador suelta la posesión del bus paraanalizar el contenido de la variable leída y establecer los *�� del Registro deEstado de acuerdo a su valor. Por último, vuelve a adueñarse del bus y realiza laescritura del cerrojo con el valor que corresponda.

Pues bien, ¿funcionaría esto en un sistema multiprocesador? La respuesta es no.Entre la lectura y la escritura del cerrojo, el bus de acceso a memoria queda libre,con lo que nada impide que otro procesador lea el contenido del cerrojo en eseintervalo y se crea con permiso para entrar en la región crítica. Para solucionar esto,suele disponerse de una instrucción TASL�4��)��1��/��), que mantiene elbus retenido para la CPU durante toda la operación de lectura y escritura del cerrojo.

Hemos dicho que “�� 5��-� �� $�� 6-� �� 5��6”. Esto es un problema, o al menos, un gasto inútil de CPU. Si el cerrojo tieneel valor 1 y el proceso que desea acceder a la región crítica está comprobando�� su valor, está claro que dicho valor no va a cambiar, al menosmientras tal proceso continúe ejecutando la instrucción TAS. Seguramente habráque esperar a que se acabe su porción de tiempo, tome control el proceso que seencuentra dentro de la región y al finalizar ponga a 0 el cerrojo. Así tenemos que elproceso que quiere entrar gasta inútilmente sus porciones de tiempo esperando aque aparezca el valor 0, cosa que nunca va a suceder mientras él tenga la posesiónde la CPU.

Por esto, a este método para conseguir la exclusión mutua se le conoce como��+�, pues el proceso espera su turno consumiendo, inútilmente, tiempode procesador.

Cuando la política de planificación de CPU es por prioridades, utilizandomecanismos de sincronización de espera activa, se puede presentar el siguienteescenario, conocido como el problema de la ��+�� .Supongamos dos procesos cooperantes, P1 con prioridad 1 (alta) que está enespera, y otro proceso P2 con prioridad 2 (baja) que está en ejecución. El procesoP2 entra en la región crítica, y antes de abandonarla, el proceso P1 sale de espera ypasa a Preparado, y debido a su mayor prioridad pasa inmediatamente a Ejecución,

��

��"� ��

por lo que al proceso P2 se le expulsa a Preparados. El proceso P1 se ejecuta hastallegar a la entrada de la región crítica, pero tras consultar el estado del cerrojo, sededica a realizar la espera activa hasta que el cerrojo quede libre. Como su prioridades mayor que la del proceso que se encuentra dentro de la región crítica (P2), nuncava a ceder el procesador, con lo que el proceso P2 no va a continuar ejecutándose ynunca abandonará la región crítica. Los dos procesos quedan bloqueados.

��40��En apartados anteriores hemos hablado sobre el ciclo de vida de un proceso,durante el cual se pasa por periodos de instrucciones de CPU y por periodos deespera de E/S. Debido a que las operaciones con recursos externos tardan muchotiempo en realizarse (incluso puede haber una cola de procesos requiriendo susservicios), los procesos que solicitan una operación de E/S pasan a estado deEspera y ceden la CPU a otro proceso, no desperdiciando así el tiempo deprocesador.

E.W. Dijkstra propuso en 1965 el Semáforo como mecanismo de sincronización.Una de sus principales peculiaridades es que evita la espera activa. La idea eratratar las regiones críticas como recursos de acceso exclusivo por los que compitenlos procesos, de tal manera que el que consigue el permiso entra en la regióncrítica, y el resto de los procesos quedan en estado de Espera hasta que les llegueel turno de acceso.

Un semáforo es un tipo abstracto de datos con dos operaciones básicas más una deinicialización (Figura 22). A las dos operaciones básicas las llamaremos #�� y�-��, aunque originalmente se llamaran 7 y ,, y posteriormente hayan recibidootros nombres muy utilizados como �� y )�8�� 49�� y� )�� . Para cadaregión crítica se declara una variable de tipo Semáforo que identifica a la regióncomo un recurso compartido.

Estas dos operaciones básicas se corresponden con los protocolos de acceso ysalida de la región crítica, tal que para entrar en ella hay que ejecutar una operaciónBajar sobre el semáforo asociado a esa región, y a la salida debe llamarse a lainstrucción Subir sobre el mismo semáforo.

Desde un punto de vista abstracto, el comportamiento de estas dos primitivas es elsiguiente:

�� !�� S ≤ 0 Esperar;S := S-1;

�� S := S+1;

Con esta descripción ya puede empezarse a entender cómo funcionan lossemáforos, pues su comportamiento es similar a las acciones realizadas con elmecanismo de espera activa. Pero ya hemos dicho que en este caso, no hay esperaactiva, así que profundicemos, con ayuda de la Figura 22, en los significados de lasoperaciones Bajar y Subir. Centrémonos en la acción �� que se realiza dentrode la operación Bajar de un semáforo. Esta acción significa:

��

�� "�

1. Meter al proceso llamante en la cola de espera de los procesos que quierenentrar en la región crítica.

2. Quitarle la CPU, pues no puede continuar la ejecución.

3. Llamar al Planificador para que seleccione un proceso de la cola Preparadosy seguidamente se le ceda el control del procesador.


�4�!��.�� * ��0��Package Semaforos is

type SEMAFOROS is private;

procedure "��#��(S : SEMAFOROS; Valor : INTEGER);

procedure $�� (S: SEMAFOROS);

procedure �� (S: SEMAFOROS);

end Semaforos;

%!��!�*��

2��3

C:@:"��⇒ 0��!��?* ��0��M�N��6 �� ?��,��?�?��

!� ��!��?* ��0��1M��!��?* ��0��+�'

��0

*,C�"��⇒ 0��!��?* ��0��Y�N��6 ��!��?* ��0��1M��!��?* ��0��&�'

!� 0�<�5?:!�K�?�� ?�� 6 �

�� !�?�� !��0��

!� ��!��?* ��0��1M�'

��0 ��0

��

��"� ��

Nos queda hablar de la inicialización del semáforo. Como ya veremos en las notassobre su implementación, un semáforo tiene un contador interno asociado, tal quecada vez que un proceso realiza una operación Bajar sobre él, se decrementa en 1,hasta llegar a cero. Por esto, el valor inicial de dicho contador indica el númeromáximo de procesos que pueden utilizar simultáneamente el recurso asociado. En elcaso de que el recurso sea una región crítica, el valor inicial del semáforo deberá ser1, pues es el número máximo de procesos que pueden acceder simultáneamente ala región. Los valores que puede tomar el contador del semáforo son, entonces, 0 y1; por esto a un semáforo de este tipo se le denomina ��40��-��.

Ahora podemos ver, en la Figura 23, la versión con semáforos de nuestro ejemplodel Observador y el Reportero. Obsérvese que el programa Cuenta_Eventoscomienza inicializando a 1 el semáforo S, y arrancando a continuación los dosprocesos.

6 LV WHP D V �2 S H UD W LY R V �, * H V W Ly Q �G H �3 U R F H V R V ��

6 H P i I R U R V � � � � �� !�

P r o g r a m C u e n t a _ E v e n t o s ;C o n t a d o r : I N T E G E R ;S : S E M A F O R O S ;

p r o c e s s O b s e r v a d o r ;r e p e a t

E s p e r a r _ E v e n t o ;$ � � � � � % � & '

C o n t a d o r : = C o n t a d o r + 1 ;� � � � � � % � & '

f o r e v e r ;e n d O b s e r v a d o r ;

p r o c e s s R e p o r t e r o ;r e p e a t

$ � � � � � % � & 'I m p r i m i r ( C o n t a d o r ) ;C o n t a d o r : = 0 ;

� � � � � � % � & 'f o r e v e r ;

e n d R e p o r t e r o ;

b e g i n" � � � � � � � # � � � % � ( � ) & 'O b s e r v a d o r ;R e p o r t e r o ;

e n d C u e n t a _ E v e n t o s ;

��

�� ""

En la Figura 24 se muestra una aproximación a la implementación del semáforo.Ciertos detalles concretos pueden variar de un sistema a otro, sobre tododependiendo de la política de planificación utilizada. Como se puede ver, unSemáforo es un registro con dos campos: el �� indicador del número deprocesos que pueden acceder al recurso, y una �� para los procesos que tenganque esperar su turno. Como comentario adicional a lo mostrado en dicha Figura 24,cabe resaltar el hecho de que las operaciones sobre el semáforo son Llamadas alSistema y, por lo tanto, desde el punto de vista del usuario, se realizan de forma��, es decir, que las instrucciones sobre la estructura de datos que componeel semáforo se ejecutan siempre en exclusión mutua. La forma de conseguir laexclusión mutua (no incluida en la Figura 24) depende de la implementaciónconcreta de cada sistema operativo.

Ya tenemos un mecanismo de sincronización que nos ha resuelto el gran problemade la espera activa, pues ya no se desperdicia el tiempo de la CPU. No obstante, sesigue manteniendo uno de los problemas de los cerrojos, esto es, sigue siendoresponsabilidad del programador el uso adecuado de las primitivas desincronización, o sea, :�� para entrar en la región crítica, y )�� para salir de ella.

Si inadvertidamente no se sigue estrictamente el protocolo de entrada y salida de laregión, o no inicializa adecuadamente el semáforo, el sistema falla.

%��Para evitar el problema de los descuidos del programador a la hora de seguir elprotocolo estipulado para acceder y salir de una región crítica, Hoare propuso en1974 una primitiva de sincronización de más alto nivel denominada ��. BrinchHansen propuso otra versión del monitor en 1975, y posteriormente ha habido otrasmás, así como también hay diversas políticas de planificación para los procesos queintervienen en un monitor.

Básicamente, un monitor es una colección de procedimientos y datos, agrupados enuna especie de módulo muy especial conocido como módulo monitor. Los procesospueden llamar a los procedimientos del monitor siempre que lo deseen, pero nopueden acceder directamente a las estructuras de datos internas del monitor desdeprocedimientos declarados fuera del monitor. Las estructuras de datos escondidasen el monitor solamente están accesibles por los procedimientos del monitor.

En la Figura 25 se muestra un monitor llamado Control_Eventos que escondeuna variable interna: Num_Eventos, y que exporta dos procedimientos de acceso ala variable: Incrementa e Imprime. En la parte inferior tenemos una versión denuestro ejemplo en la que se utiliza el monitor.

Los monitores tienen una propiedad especial para conseguir la exclusión mutua:“)��;��”. Dicho deotra forma, dado un proceso A que ha llamado a un procedimiento de un monitor, ymientras se está ejecutando dicho procedimiento, toma el control de la CPU otroproceso B, si este proceso B llama a cualquier procedimiento del monitor, el procesoB quedará detenido en la entrada (en estado de Espera) hasta que el proceso Aabandone el monitor.

��

��"& ��


* ��0�� ! � ��type SEMAFOROS is private;procedure "��#��(S : SEMAFOROS; Valor : INTEGER);procedure $�� (S : SEMAFOROS);procedure �� (S : SEMAFOROS);private -- Inaccesible al usuario

type SEMAFOROS isrecord

Contador : INTEGER;Cola : COLA_PROCESOS;

end;--procedure "��#�� (S : SEMAFOROS; Valor : INTEGER) isbegin

S.Contador := Valor;end Inicializar;

procedure $�� (S : SEMAFOROS) isbegin

if S.Contador < 1 thenEncolar (Este_Proceso, S.Cola);Suspender; -- Implica llamada al Planificador

elseS.Contador := S.Contador - 1;

endif;end Bajar;

procedure �� (S : SEMAFOROS) isProceso : ID_PROCESO;

beginif s.Cola.Primero /= 0 then -- Si algun proc. Esperando

Desencolar (Proceso, S.Cola);Preparar (Proceso); -- Llamada al Planificador

elseS.Contador := S.Contador + 1;

endif;end Subir;

��

�� "'


�4�!��.�� .��%�� 0�� J�� /��

*�� 2�� /��K� ��/��!��!3

��:��

�� !�#� ��

,��.�� !�� !�2.��3�

*�!��

�L�%,*�8�.,$,:

Module Monitor Control_Eventos;Num_Eventos : INTEGER;procedure "�� is

Num_Eventos := Num_Eventos + 1;end Incrementa;

procedure "�� isImprimir (Num_Eventos);Num_Eventos := 0;

end Imprime;

process Observador;repeat

Esperar_Evento; ��*"��'

forever;end Observador;

process Reportero;repeat

��*"��'Hacer_Otras_Cosas;

forever;end Reportero;

��

��"( ��

Los monitores son una construcción de los lenguajes de programación, de tal formaque los compiladores saben que las llamadas a los procedimientos de un monitor semanejan de forma distinta a las llamadas a los procedimientos convencionales.Normalmente, en la llamada de un proceso a un procedimiento de un monitor, lasprimeras instrucciones del procedimiento son para comprobar si algún otro procesose encuentra dentro del monitor; si es así, el proceso llamante queda bloqueadohasta que el otro proceso salga del monitor. Si no hay ningún proceso dentro delmonitor, el proceso llamante puede entrar y continuar la ejecución.

La implementación de la exclusión mutua en las entradas del monitor es labor delcompilador. Normalmente suele realizarse con ayuda de un semáforo binario, de talforma que en el prólogo de un procedimiento de monitor, se incluye una llamada aBajar(S), y a la terminación del procedimiento se llama a Subir(S), siendo S unsemáforo asociado a cada monitor.

Ya que es el compilador, no el programador, el que se ocupa de cumplir el protocolode acceso a la región crítica, es mucho más difícil que algo se haga mal o que seproduzca algún olvido. En cualquier caso, la persona que escribe un monitor notiene por qué saber cómo implementa la exclusión mutua el compilador. Le bastacon saber que metiendo las regiones críticas en monitores, nunca habrá más de unproceso dentro de la misma región crítica al mismo tiempo.

Puesto que cuando un proceso se encuentra dentro de un monitor, no puede entrarotro proceso, debe evitarse que el proceso que está dentro pueda quedarsebloqueado en estado de Espera, o sea, que no debe ejecutar llamadas al sistemaque lo pasen a tal estado. Sin embargo hay situaciones en las que se requiere pasara Espera. Para ello, existen otras construcciones, para que cuando un procesodentro de un monitor deba pasar a espera, se permita la entrada a algún otroproceso que esté esperando para entrar. Aunque estas construcciones (las ��), no vamos a tratarlas en estos apuntes, puede obtenerse una descripcióndetallada consultando la bibliografía de referencia.

��!�%� ��#��Aunque los semáforos y los monitores son buenos mecanismos para lasincronización de procesos todavía tienen algunas pegas: los semáforos son dedemasiado bajo nivel, y los monitores solamente están disponibles en unos pocoslenguajes de programación.

Otro problema con los monitores y los semáforos es que están diseñados pararesolver el problema de la exclusión mutua en sistemas con una o más CPU’s quecomparten una memoria común. Pero cuando se trata de un sistema distribuido,formado por múltiples procesadores, cada uno con su propia memoria particular yconectados por una red de área local, estas primitivas se vuelven inservibles, puesya no hay variables compartidas, y ninguno de estos mecanismos proporcionaintercambio de información entre máquinas. Se necesita algo más.

��

�� ")


�� . ��

��!�� !� �!�� ! ��

��6�5�� ! ��

��'

��(

��2. �� 3 " � ��2. �� 3

��2. �� 3" � ��2. �� 3

:%;,�:*��,�*$�)��*

�!��!�� * �

,�� !

C�� !

�. ��

�C��<��R��

�" ��

$��O�� !�. �� H��

�� !

.�� !��%��

��-�"��$:��-�"��$:

��*�.Z$"��:�)�:*�.Z$"��:

�� !�C�J�

�

�

�

�

��

��&* ��

Ese algo más es el ��. La función del paso de mensajes es permitirque dos procesos se comuniquen sin necesidad de utilizar variables compartidas.Este método de comunicación entre procesos ofrece, al menos, dos primitivas:�� y &��, que, a diferencia de los monitores, no son construcciones dellenguaje de programación, sino Llamadas al Sistema, por lo que para utilizarlasbasta con llamar a los correspondientes procedimientos de biblioteca.

Mediante �� se expide un mensaje a un proceso destino, mientras que con&�� se indica el deseo de recibir un mensaje de algún proceso fuente. Si no hayningún mensaje disponible, el proceso receptor puede quedarse bloqueado hastaque llegue uno.

El paso de mensajes no es de uso exclusivo de sistemas con múltiplesprocesadores (con o sin memoria común), sino que es válido para cualquier sistemamultiproceso, ya sea con una o más CPU’s, o con memoria compartida o local acada procesador, pues su semántica solamente indica el paso de información de unproceso a otro. Esta independencia del hardware subyacente hace que losprogramas que utilizan paso de mensajes como mecanismo de sincronización ycomunicación sean más portables entre distintas máquinas, pues sólo requieren quedispongan del mismo sistema operativo. (Obsérvese que esto no quiere decir quepara que dos procesos que se ejecutan en máquinas distintas puedan comunicarse,tengan que ejecutarse sobre el mismo sistema operativo; simplemente tienen queutilizar el mismo protocolo de comunicación).

Si dos procesos � y : quieren comunicarse, deben enviarse y recibir mensajes, porlo que debe establecerse un �� entre ellos. Este enlacepuede implementase de distintas maneras. Aquí no vamos a tratar laimplementación física del enlace (memoria compartida, un bus o una red), que esmás propia de los cursos de comunicación de datos, sino que vamos apreocuparnos de los aspectos lógicos de la implementación. Así, estudiaremoscuestiones relacionadas con los siguientes puntos:

• ¿Cuál es el tamaño de los mensajes? ¿El tamaño es fijo o puede ser variable?

• ¿Un enlace puede ser unidireccional o bidireccional? Es decir ¿los mensajessolamente pueden viajar en un sentido, o en ambos?

• Modelos de comunicación: comunicación directa o indirecta, simétrica oasimétrica.

• La información se puede enviar por copia o por referencia.

En cuanto al tamaño de los mensajes que se envían los procesos, pueden ser delongitud fija o variable. Si sólo se permiten mensajes de longitud fija, laimplementación del sistema es más fácil, pero tal restricción dificulta la tarea delprogramador.

Veamos el resto de las cuestiones enumeradas en los siguientes apartados.

��

�� &�

��!�%��

Primero debemos decir que los procesos reciben mensajes en �;��. Es decir,que cuando un proceso envía mensajes, estos van a parar a buzones, y losprocesos que quieren recibirlos tendrán que sacarlos de esos buzones.

Los procesos que desean comunicarse deben disponer de una manera explícita deindicar el destino del mensaje que se envía, o el remitente del mensaje que sequiere recibir, y esto depende de que la comunicación sea !�� o 0��.

��>��En la comunicación directa de envío de mensajes, tanto el emisor como el receptordeben indicar explícitamente el proceso destino o remitente del mensaje. Así, lasprimitivas de envío y recepción tendrán el siguiente aspecto:

��47��3!��-�<�� =��47��3#��-�<�� =

Como se puede apreciar en el esquema superior de la Figura 27, cada proceso tienesu propio buzón de recepción de mensajes.

Una comunicación de este tipo tiene las siguientes características:

• Automáticamente se establece un enlace entre cada par de procesos que sequieren comunicar.

• Cada uno de ellos necesita saber la identidad del otro proceso con el que sequiere comunicar.

• Un enlace asocia únicamente a dos procesos.

• Entre cada par de procesos solamente existe un enlace.

• El enlace o comunicación puede ser unidireccional o bidireccional.

En la Figura 27 también tenemos a nuestros dos procesos, el Observador y elReportero, comunicándose por mensajes. Tal comunicación es directa,unidireccional (el Observador sólo envía, y el Reportero solamente recibe) y��7��, pues tanto el emisor como el receptor necesita conocer el nombre delotro proceso.

Una variante dentro de esta comunicación directa, es que el modelo sea ��7��(esquema inferior de la Figura 27), es decir, que puede haber múltiples procesosenviando mensajes a un único receptor, en cuyo caso el proceso receptor no tieneque indicar de qué proceso quiere recibir mensajes. En la comunicación asimétrica,la llamada al sistema para enviar mensajes permanece invariable, mientras que lade recepción, queda así:

��40�37��-�<�� =

Donde ambos parámetros son de salida. 0�37�� contendrá el identificador delproceso que envió el <�� recibido.

��

��&� ��


�� . �� -� �� J��

�� !�� 4�!�� !�� !��

repeat. . .Esperar_Evento. . .��%��(+��&

forever

repeat. . .��%��(+��&. . .Imprimir_Evento

forever

) � �� " ��

��'

��(

��2�(/�. �� 3 " � ��2�'/�. �� 3

��2�'/�. �� 3" � ��2�(/�. �� 3

��#� ��*�.Z$"��)

) ��'

) ��(

) ��=

" ��

��2" �� /�. �� 3[

��2" �� /�. �� 3[

��2" �� /�. �� 3[

" � ��2" �� /�. �� 3[

��#� ��:*�.Z$"��)� �� !��-� ��

*�� !�� /6�5�#� �� !�� 0 � ��!

��

�� &�

La desventaja que presenta este modelo de comunicación directa (tanto el simétricocomo el asimétrico), es el problema que se plantea con el mantenimiento de losnombres de proceso. Es decir, en un programa, que puede estar formado pormuchos módulos, si se cambia el identificador de un proceso hay que revisar todoslos módulos para comprobar y modificar todas las referencias a tal proceso, paraque indiquen el nuevo identificador.

�� Con la comunicación indirecta, los mensajes se envían a buzones, no a procesos, y,análogamente, el receptor debe indicar el buzón del que quiere recibir un mensaje,no de qué proceso. Véase el croquis superior de la Figura 28.

Un buzón se puede ver como un objeto en el que se pueden poner y retirarmensajes. Cada buzón tiene un identificador único. Según este esquema, unproceso puede comunicarse con otros procesos mediante distintos buzones. Lasprimitivas de envío y recepción de mensajes quedan así:

��4:;��-�<�� =��4:;��-�<�� =

siendo :;�� el identificador del buzón al que se envía o del que se desea recibir unmensaje.

Observando el citado croquis de la Figura 28, puede verse que, ahora, un enlace decomunicaciones tiene las siguientes propiedades:

• Dos procesos solamente pueden comunicarse entre ellos si comparten unbuzón.

• Un enlace de comunicaciones puede estar asociado a más de dos procesos.

• Entre cada pareja de procesos comunicantes puede haber varios enlaces,donde cada enlace corresponde a un buzón.

• Un enlace puede ser unidireccional o bidireccional.

Este modelo de comunicación indirecta ya no adolece del problema delmantenimiento de los nombres o identificadores de procesos que se producía en lacomunicación directa, pues ahora nunca se nombra el proceso destino u origen, sinoun buzón común. Este esquema de comunicaciones es similar al servicio de�� que ofrecen las compañías postales. La comunicaciónmediante un apartado de correos, es independiente de la dirección o domicilio realde la persona o entidad a quien se dirige la correspondencia, ya que ésta se le envíaindirectamente, vía un apartado de correos, y aunque el destinatario cambie dedomicilio, basta con que siga yendo a recoger la correspondencia al cajetín delapartado de correos para que la comunicación siga siendo efectiva. Obviamente, lacomunicación se mantiene en tanto en cuanto se mantenga invariable el nombre delbuzón o apartado de correos común. Pero mientras que los cambios de domicilio

��

��&� ��


�� . ��

) ��'

) ��(

) ��=

" ��'

Enviar (Buzón_1, Mensaje) Recibir (Buzón_1, Mensaje);

Enviar (Buzón_1, Mensaje)Enviar (Buzón_2, Mensaje)

" ��(

C�J�?'

C�J�?(

Enviar (Buzón_2, Mensaje)

��

Recibir (Buzón_2, Mensaje);

Recibir (Buzón_2, Mensaje);

��

'��" �?'�5�" �?(� � ��Recibir (Buzón_2, Mensaje)(��) �?(� �� !�C�J�?(

�� !�� ) �?(��

Procedure ��$�#� (Nombre : in Nombres; Buzon : out Buzones);

procedure ��$�#� (Nombre : in Nombres; Buzon : out Buzones);

procedure �� (Buzon : in Buzones; Mensaje : in Mensajes);

procedure �� (Buzon : in Buzones; Mensaje : out Mensajes);

procedure ,��$�#� (Buzon : in out Buzones);

�!�*�� )� ��0� � �� 1

��

�� &"

son previsibles, no hay razón para no seguir manteniendo el mismo apartado decorreos, y así nadie se ve afectado por el cambio de dirección.

Cuando la comunicación es indirecta, se pueden tener varios buzones decomunicación entre dos procesos, con lo que se puede enviar mensajes a uno u otrobuzón, dependiendo del motivo o importancia de cada mensaje.

Obsérvese que, debido a la flexibilidad que ofrece este esquema, se puede tenercualquier combinación numérica de procesos productores y consumidores demensajes:

• Un productor- un consumidor• Varios productores - un consumidor• Un productor - varios consumidores• Varios productores - varios consumidores

Las primitivas de gestión de buzones y mensajes varían según el sistema operativo.No obstante, en el cuadro inferior de la Figura 28 podemos ver las primitivas que sesuelen ofrecer para estos servicios:

• Crear un buzón.• Conectarse a un buzón.• Enviar y recibir mensajes de un buzón.• Destruir un buzón.

Para crear un buzón, se llama a la primitiva correspondiente, indicando comoparámetro de entrada el nombre del buzón, esto es, una tira preestablecida decaracteres (al igual que los nombres de ficheros), y el sistema crea el buzóndevolviendo como parámetro de salida el ��0�� -�1�� creado. Esteidentificador es el que se debe utilizar en el resto de las operaciones que se realicencon ese buzón.

Cuando varios procesos vayan a comunicarse mediante un buzón, uno de ellos (elpropietario) lo debe crear y, posteriormente, el resto debe conectarse a él, puesconocen de antemano el nombre del buzón a compartir. Seguidamente ya puedenrealizar las operaciones de envío y recepción de mensajes utilizando el identificadorde buzón.

El proceso propietario del buzón debe ocuparse de destruir el buzón cuando no serequieran más sus servicios, para liberar la memoria y recursos del sistema que seutilizan en la gestión del buzón.

��!�%�� .�,�

Un buzón tiene una capacidad que determina el número de mensajes que puedetener almacenados temporalmente. Este almacén se puede ver como una cola demensajes asociada al buzón. Básicamente hay tres posibilidades sobre el tamañodel buzón:

��

��&& ��

• ��9��La cola tiene una longitud máxima finita (� mensajes), lo que quiere decir que,como mucho, podrá haber � mensajes en el buzón esperando a ser recibidos poruno o varios procesos. Así, si la cola no está llena, cuando un proceso envía unmensaje, éste se encola en el buzón, y el emisor puede continuar la ejecución sinninguna espera. El proceso receptor podría estar esperando a recibir un mensaje,con lo que ahora ya podría recibirlo y continuar también la ejecución; perotambién es posible que no hubiera todavía ningún proceso esperando por elmensaje, en cuyo caso, el mensaje simplemente queda encolado en el buzónhasta que un proceso quiera recibirlo. No obstante, ya que el tamaño del buzónes limitado, si al enviar un mensaje a un buzón, éste está lleno, entonces hay dosalternativas:

- El proceso emisor queda bloqueado en espera de que haya espacio libre enel buzón.

- Como parámetro de salida en la llamada a ��, se le indica un �� deerror indicativo del llenado del buzón. En este caso, el proceso emisor no sebloquea, y se deja en sus manos la decisión de reenvío o no del mensaje.

La técnica habitual de implementar estos buzones es mediante un buffercircular.

• ��9=��La cola de mensajes tiene una longitud potencialmente infinita, por lo que puedealbergar cualquier número de mensajes, y por lo tanto, el emisor nunca quedabloqueado.

Los buzones de capacidad ilimitada suelen implementarse como una listaencadenada de mensajes, por lo que la limitación sólo está en la cantidad dememoria que el proceso tiene disponible.

• ��<��La longitud máxima de la cola de mensajes es cero, por lo que no puede habermensajes en el buzón esperando a ser recibidos. En este caso, el emisor oremitente que quiera enviar un mensaje debe esperar hasta que el destinatarioreciba el mensaje. Así, los dos procesos deben ponerse de acuerdo en elmomento de realizar el envío/recepción del mensaje para que la transferenciatenga lugar. En este caso se dice que la comunicación es �=��. A estacomunicación síncrona también se le conoce con el nombre de ��;�� (cita).

Se debe hacer notar que cuando la capacidad del buzón no es cero, el procesoemisor no sabe cuándo un mensaje enviado ha llegado a su destino, pues no tieneque esperar a que el proceso destino lo reciba (comunicación ��=��), y estopuede ser crucial para el normal desarrollo del programa. En este caso, el receptordebería comunicarse explícitamente con el emisor para hacerle saber que harecibido el mensaje.

��

�� &'


�� . �� !�C�J�

��%��2�� 3

*�6�5� ��⇒��!� ��K��!�� !� ��

*� ��!! ��⇒��!� ��#� �� !�#� ��6��#� ��6�5�� !� �J��

��* �� !� ��M�!! ��

��!��!� �� !�#� �� !� ��

��!��!� ��#� �� !�#� ��6��#� � !�� !�� !��

�� !��

��!��"#$%�

��!�� J�� Y�N�� !� ��#� � !�� 6��!! ��

PROCESO P1:Enviar (P2, Mensaje);Recibir (P2, Mensaje);

PROCESO P2:Recibir (P1, Mensaje);Enviar (P1, Mensaje);

<�5�#� �0��J�� !��

��

��&( ��

��Vamos a comentar ahora un nuevo tipo de procesos que en los últimos años asurgido con fuerza entre los sistemas operativos y que se adapta especialmentebien a la estructura de los sistemas con múltiples procesadores: los �� oprocesos ligeros.

Para que un programa pueda ejecutarse (convertirse en proceso) se requieren doselementos:

• Un procesador.• Un entorno de ejecución.

El entorno de ejecución se refiere al resto de los recursos (además del procesador)que necesita un programa para ejecutarse. Así, por ejemplo, sabemos que senecesita un área de memoria para acoger el código del programa, un área dememoria para ubicar las variables globales, otro área de memoria, denominado��, de donde se sirven las peticiones dinámicas de memoria, y por último tambiénse necesita un área de memoria para albergar la pila de trabajo. Una vez que elproceso está cargado en memoria puede comenzar su ejecución. Con memoriavirtual, el comienzo de la ejecución va a implicar que todas las primeras referenciasa memoria generen una falta de página, tanto en la caché como en memoriaprincipal, por lo que se deberá dedicar un tiempo a la carga de páginas inicialeshasta que se consiga el conjunto de trabajo estable. También es normal que unproceso haga operaciones de E/S con ficheros, por lo que será necesario abrir losficheros con los que se vaya a trabajar, y durante la ejecución se tendrán �**�� deE/S asociados con cada dispositivo o fichero. Como nos podemos imaginar serequiere cierto tiempo para conseguir un entorno de ejecución estable.

Los procesos tradicionales (como los de Unix) se crean de tal forma que compartenel procesador (en un entorno monoprocesador) y a cada uno se le asigna un entornode ejecución diferente, es decir, cada uno tiene sus áreas de memoria, sus tablas depáginas, sus descriptores de los ficheros que maneja, sus �**�� de E/S,semáforos, etc. Y esto, que parece razonable, se hace para todos los procesos delsistema, es decir, se trata a todos los procesos del sistema como si fuerantotalmente disjuntos y que lo único que comparten es el procesador.

Ahora bien, hay situaciones en las que un trabajo laborioso, puede descomponerseen varias subtareas o subprocesos, de tal forma que todos ellos cooperan en laconsecución de un mismo fin. En estos trabajos es normal que haya muchacomunicación y compartimiento de datos entre los subprocesos componentes. Elmecanismo normal de comunicación en estos casos son los mensajes, que no dejade ser un mecanismo costoso en tiempo. La comunicación entre procesos pormemoria compartida, aunque rápida, es peligrosa, pues un proceso malintencionadopodría machacar áreas de memoria de otro proceso con el que comparte memoria,sin embargo esto no es normal en procesos cooperantes.

��

�� &)


��

�� #� �

�� ! ��!� �! �H�6 �� $ ��J�� 6��* O�! �* ��0�� !��

�� .��AFNNN

�� !�" �� " �� ! ��

�� 4��

�� !��

��

+�H�!�� +�H�!�� 6�+�: ��0�6 ��+�%! �� 00 �� I*

� � �� -��

��")��

�� ,�-��).�:"$�"

"��,"*)*

�!� �!�

��

��

�' �(

�!� �!�

��

��

�' �(

�� "��

�� "�� 4��

��

��'* ��

Hemos visto que la creación de un proceso puede ser un tanto costosa, pues creaun entorno de trabajo totalmente diferente para cada uno. Sin embargo, paraprocesos cooperantes parece que no se requieren entornos totalmente distintos,pues es muy posible que prefieran áreas de memoria comunes para compartir datos(a su propio riesgo) y comunicarse rápidamente. Es más, seguramente prefierencompartir las memorias caché, y los �**�� de E/S, pues parte de los datos quemanejan van dirigidos o provienen de las mismas fuentes. Dos o más procesosgemelos cooperantes podrían compartir incluso el área de código. Según esto, lacreación de procesos cooperantes requeriría un entorno de trabajo muy reducido: lapila de trabajo y, en caso de procesos no gemelos, un área de memoria para elcódigo. Esto traería ventajas por dos vertientes:

• Creación rápida de procesos• Cambio rápido de contexto

Debemos darnos cuenta de que, en este escenario, la conmutación del entorno detrabajo entre dos procesos cooperantes puede ser muy rápida, pues solamente hayque cambiar los registros del procesador (lo cual implica un cambio de pila detrabajo y de contador de programa). El proceso que asume la posesión delprocesador va a seguir utilizando las mismas áreas de memoria para datosestáticos, código (si los procesos son gemelos), ficheros, �**�� de E/S. Elcompartimiento de memoria va a implicar, además, que al cambiar de contexto nose van a vaciar las cachés y no se van a producir faltas de página en las primerasreferencias a memoria, con lo que se evitan más pérdidas de tiempo.

Por lo visto hasta ahora, parece que sería interesante que los sistemas operativosofrecieran dos tipos de procesos (cooperantes y no cooperantes), con suscorrespondientes primitivas de creación, gestión, comunicación y sincronización.

Prácticamente todos los núcleos de sistemas operativos para sistemas distribuidosofrecen los dos tipos de procesos, y estos son los nombres que les han dado:

?��-� �� Proceso�6�� Actor%��6 �� Tarea@�A�� Proceso Equipo (��)

Aunque los distintos sistemas operativos no se han puesto totalmente de acuerdo,los nombres más extendidos son los proceso, tarea o proceso pesado para losprocesos tradicionales (los que tienen un entorno de trabajo totalmente diferente delos demás procesos), y �� o �� para los procesos cooperantes quequieren compartir el entorno de trabajo.

Windows/NT, OS/2 y Solaris (Unix de Sun) son algunos ejemplos de sistemasoperativos comerciales que disponen de ��.

��

�� '�


&&&��

"�� #� ��

$�� %�� :��% �� $�� &� '�� #��2��3

��

�� %� ��

��

��

.�5��K� ��

��

. �� 6�� !��

%��*�-�� !��

0��6��

�#� ��(�%��

�� ''�� '/F��

)��* '�� N/NNB��*� � �� :L�� -�;�$:%

��

�J�

��6�

��

� ��

":.��

��

��'� ��

A los programas con �� se les saca más provecho en aplicaciones compuestasde múltiples procesos cooperantes, y esto es algo que se suele dar mucho en lossistemas distribuidos, en los que por su filosofía cliente-servidor se prestan mucho aeste tipo de aplicaciones. Debido a la premura de tiempo no vamos a profundizar enesta justificación, no obstante, se recomienda echar un vistazo a los capítulosdedicados a �� de los textos indicados en la bibliografía, en los cuales puedenencontrarse numerosos ejemplos de situaciones de programas en las que semuestran beneficios de los �� frente a los procesos convencionales.

Algunos datos sobre los tiempos creación de procesos nos pueden ayudar aconvencernos de las ventajas de los ��. La creación de un proceso Unix sobreun procesador CVAX de DIGITAL requiere 11 milisegundos, mientras que lacreación de un ��- en un kernel llamado Topaz, sobre el mismo procesadorsolamente necesita 1 milisegundo. Los tiempos de cambio de contexto entreprocesos Unix oscilan alrededor de 1,8 milisegundos, siendo solamente 0,4 ( y enalgunos casos 0,004) entre �� de Topaz. A estos datos habría que añadir losbeneficios que se ganan a largo plazo, es decir, el tiempo que no se pierde encargar de nuevo las páginas de memoria virtual, de la caché, creación desemáforos, apertura y cierre de ficheros, llenado de �**�� de E/S, etc.

[002] Sistemas Operativos - Gestion de Procesos

Documents

Transcript of [002] Sistemas Operativos - Gestion de Procesos