Está en la página 1de 30

c 

Un proceso es un programa en ejecución, los procesos son gestionados por el sistema operativo y están
formados por:

@ Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador.


@ Su estado de ejecución en un momento dado, esto es, los valores de los registros de la CPU para
dicho programa.
@ Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos.
@ Otra información que permite al sistema operativo su planificación.

Esta definición varía ligeramente en el caso de sistemas operativos multihilo, donde un proceso consta de uno
o más × , la memoria de trabajo (compartida por todos los hilos) y la información de planificación. Cada hilo
consta de instrucciones y estado de ejecución.

Los procesos son creados y destruidos por el sistema operativo, así como también este se debe hacer cargo
de la comunicación entre procesos, pero lo hace a petición de otros procesos. El mecanismo por el cual un
proceso crea otro proceso se denomina bifurcación (). Los nuevos procesos pueden ser independientes y
no compartir el espacio de memoria con el proceso que los ha creado o ser creados en el mismo espacio de
memoria.

En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia estriba en que
un proceso solamente puede crear hilos para sí mismo y en que dichos hilos comparten toda la memoria
reservada para el proceso.

c   
 c  

Conjunto de datos en donde se incluyen el estado en cada momento, recursos utilizados, registros, etc.
El PCB pretende cubrir:

‡ Localizar la información sobre el proceso del sistema operativo.


‡ Mantener registrados los datos del proceso en caso de tener que suspender su ejecución.

La información contenida en el bloque de control es el siguiente:

‡ Estado del proceso(Información relativa al contenido del contador de programa)


‡ Estadísticas de tiempo y ocupación de recursos(Planificación del procesador)
‡ Recursos en uso(unidades de entrada/salida)
‡ Archivos en uso
‡ Privilegios



£ c 

‡   
Los procesos no se comunican entre si.
‡  
Los procesos realizan su función de modo independiente y se sincronizan
puntualmente para realizar alguna acción. (Proyecto SETI)
‡   
Los procesos se sincronizan y comunican entre si para competir por los recursos del
sistema
  

Los bloques de control de proceso se almacenan en colas cada una de las cuales representa un estado
particular de los procesos.
Los estados de los procesos son internos del sistema operativo y transparente para el usuario. Para el usuario
común los procesos siempre estarán en ejecución
Los estados de los procesos se pueden dividir en 2 tipos:

1) Activos: Son todos aquellos procesos que compiten con el procesador.


‡  : Estado que se encuentra en un proceso, cuando tiene el control del procesador.
‡ c  : Son todos aquellos procesos que están dispuestos a ser ejecutados, pero no lo están por
alguna causa.
‡  : Son todos aquellos procesos que no pueden ejecutarse por necesitar de algún recurso
(e/s).

2) Inactivo: Son procesos que aún no han terminado su trabajo por diferentes causas. Pero pueden volver
activarse nuevamente sin tener que comenzar desde el principio.
‡    : Proceso que está suspendido en espera, que ha desaparecido por una
causa de bloqueo.
‡  c  :Proceso suspendido, pero no tiene causas para estar bloqueado.


£    

Puede cambiar de estado varias veces a lo largo de su existencia

‡    : Todo proceso comienza al ser dada la orden de ejecución.
‡ c    
Se encuentra en espera de ser ejecutado.
‡ c      
 Proceso que se encuentra en ejecución y solicita una
operación externa(unidad de entrada/salida), teniendo que esperar a que dicha ejecución
finalice pasara al estado bloqueado.
‡ c   c  
Este proceso debe contener:
‡ Orden de ejecución de los procesos
‡ Proceso debe pasar a estado preparado
‡ Luego el proceso pasa a estar activado
‡ c    
Si un proceso está bloqueado y el S.O. recibe la orden de
suspendido pasa a estar suspendido bloqueado.
‡ c    c  : Este proceso debe contener:
‡ Suspensión de un proceso para pasar a preparados.
‡ Suspensión de un proceso en ejecución, con lo cual pasa a la cola de suspensión
preparado.
‡ Desbloqueo de un proceso suspendido.

    

Un proceso es simplemente, un programa en ejecución que necesita recursos para realizar su tarea: tiempo
de CPU, memoria, archivos y dispositivos de E/S. El SO es el responsable de:

@  : Se produce con la orden de ejecución de programa y suele necesitar varios argumentos,


como el nombre y la prioridad del proceso. Aparece en este momento el PCB que será insertado en
la cola de procesos preparados. La creación de un proceso puede ser de dos tipos

‡    
en ella cada proceso que se crea es hijo del proceso creador y hereda el
entornodeejecución de su padre
‡     
cada proceso creado por otro proceso se ejecuta independientemente de su
creador con u entorno diferente. Es un tipo de creación que no suele darse en sistemas
operativos actuales

@   
Se trata de la orden de eliminación del proceso con la cual el sistema operativo destruye
el PCB
@ 
Es una operación de alta prioridad que paraliza un proceso que puede ser reanudado
posteriormente. Suele darse en ocasiones de mal funcionamiento o sebrecarga del sistema
@ ^ 
Trata de activar un proceso que ha sido previamente suspendido
@     

@ £       
Hace que un determinado proceso se ejecute cada cierto tiempo
(segundos, minutos, horas) por etapas o de una sola vez, pero trascurrido un período de tiempo fijo
@ 
Es una forma de desbloquear un proceso que habrá sido bloqueado previamente por
temporización o cualquier otra causa


c        

  

En este capítulo se estudian las distintas políticas y mecanismos más comunes que poseen los
sistemas operativos actuales para realizar la gestión del procesador que se conoce con el nombre de
planificación, cuyo objetivo principal es el de dar un buen servicio a todos los procesos que existan en un
momento dado en el sistema.

En general, se distinguen varios niveles de planificación, como se refleja en la Figura.

c
  
     
      Decide cuál será el próximo trabajo que se va a
ejecutar. Este nivel sólo existe en los sistemas de proceso por lotes, donde la decisión se basa en las
necesidades de recursos y su disponibilidad. En los sistemas de tiempo compartido tiene como única misión
cargar los programas que se desean ejecutar en memoria. Este nivel es, por tanto, el encargado de crear los
procesos.

@ c
  
     
     
 Decide si un proceso que está en
ejecución en estado bloqueado o suspendido debe ser extraído de la memoria temporalmente.
Posteriormente, cuando el sistema se encuentre más descargado, devolverá dicho proceso a la
memoria y al estado de ejecución. Este nivel, por tanto, gestiona los procesos suspendidos en
espera de algún recurso no disponible en el momento de la suspensión.

@ c
  
     
          Es el encargado de decidir cómo y
cuándo tendrá acceso al procesador un proceso que está preparado para utilizarlo. Por tanto, lleva a
cabo las funciones de la multiprogramación, estando siempre residente en memoria y ejecutándose
con mucha frecuencia; por ello, debe ser de ejecución muy rápida. En este nivel es donde se debe
dar un buen servicio a los procesos interactivos para que el usuario no perciba, o lo haga en pequeño
grado, que está compitiendo por el procesador junto con otros usuarios.

 

Las políticas de planificación intentan cubrir los siguientes objetivos:

@ -  La política debe ser lo más justa posible con todo tipo de procesos, sin favorecer a unos y
perjudicar a otros.
@ 0         
: Debe dar un servicio aceptable para que todos los trabajos se
realicen lo más rápidamente posible. Esto se logra disminuyendo el número de cambios de proceso.
@ 0 
   
  : En los sistemas de tiempo compartido se tratará de que
puedan estar trabajando el mayor número de usuarios simultáneamente.
@ c      La política de planificación debe concebirse de tal forma que en todo momento
pueda saberse cómo será su ejecución.
@ 0
 
       La computadora debe tener poca sobrecarga ya que ésta incide
directamente sobre el rendimiento final del sistema: a menor sobrecarga, mayor velocidad de
proceso. Por ello, los cambios de contexto deben minimizarse.
@ 3 
     Para obtener un buen rendimiento en el uso de los recursos y que
éstos estén ocupados equitativamente el mayor tiempo posible.
@ ©        . Si un proceso tiene mayor prioridad que otro, éste debe ejecutarse
más rápidamente.

Los objetivos enunciados pueden entrar en ocasiones en contradicción; por ello es necesario llegar a
una situación de compromiso entre todos los objetivos para conseguir del sistema operativo un buen
rendimiento y un buen servicio.

 

Los criterios que se deben tener en cuenta a la hora de elegir o diseñar un algoritmo de planificación
son los siguientes:

@ £   : Velocidad con que el ordenador da respuesta a una petición. Depende
mucho de la velocidad de los dispositivos de entrada/salida.
@ £    Es el tiempo que tarda en ejecutarse un proceso, donde se incluye el tiempo
de carga del programa en memoria, el tiempo de espera en la cola de procesos preparados, el
tiempo de ejecución en el procesador y el tiempo consumido en operaciones de entrada/salida.
@ £    
 Es idéntico al tiempo de servicio menos el tiempo de espera en la cola de
procesos preparados; es decir, es el tiempo teórico que necesitaría el proceso para ser ejecutado si
fuera el único presente en el sistema.
@ £       Es el tiempo que un proceso está utilizando el procesador sin contar el
tiempo que se encuentra bloqueado por operaciones de entrada/salida.
@ £   Es el tiempo en que los procesos están activos pero sin ser ejecutados, es decir,
los tiempos de espera en las distintas colas.
@ 3 
 Se refiere a la utilización del recurso más caro en un sistema, el procesador, que debe
estar el mayor tiempo posible ocupado para lograr así un gran rendimiento.
@ ^

 Es el número de trabajos o procesos realizados por unidad de tiempo, que debe ser lo
mayor posible.

Ahora bien, ¿qué algoritmo de planificación se debe elegir para un sistema determinado? Será misión del
diseñador del sistema operativo la elección de los mecanismos apropiados para que la política elegida
partiendo de los criterios anteriores sea satisfactoria y ofrezca un alto rendimiento global.

0  

Para estudiar el comportamiento de las distintas políticas de planificación, definiremos dos medidas
relacionadas entre sí que nos indiquen cómo estamos tratando un proceso concreto.

Consideremos t como el tiempo que un proceso P necesita estar en ejecución para llevar a cabo su trabajo, ti
el instante en que el usuario da la orden de ejecución del proceso y tf el instante en que el proceso termina su
ejecución. En función de estos datos, tendremos las siguientes medidas para cada proceso:

£     £
T = tf - ti

£   
E = T - t
A partir de los dos valores anteriores, podemos establecer una relación que nos permite evaluar la actuación
de la política establecida en lo que se denomina índice de servicio (I).

I=t/T

Este índice representa el tanto por uno de tiempo que el proceso está en ejecución respecto al tiempo de vida
del mismo en el sistema.

En caso de que sólo exista un proceso ejecutándose en el sistema, según el valor del índice de servicio,
podemos decir que:

Cuando  sea próximo a la unidad, el proceso está limitado por proceso.

Si  tiene un valor bajo próximo a 0, el proceso estará limitado por entrada/salida.

En los casos más usuales en los que existe más de un proceso en el sistema, no podemos hacer las
consideraciones anteriores puesto que puede desvirtuarse el verdadero comportamiento del sistema. Por este
motivo se establecen las mismas medidas, pero con valores medios obtenidos al considerar el conjunto de
procesos presentes. Estas serán las medidas que nos reflejarán el verdadero comportamiento del sistema.
Las medidas a las que nos referimos son:

@ Tiempo medio de servicio.

@ Tiempo medio de espera.

@ Eficiencia (índice medio de servicio).

Además de las anteriores, en la planificación del procesador suelen emplearse otras dos medidas de
interés:

@ £ 
  Es el tiempo consumido por el núcleo del sistema operativo para tomar las
decisiones de planificación del procesador, donde se incluyen los tiempos de cambio de contexto y
de proceso.
@ £ 
     Es el tiempo consumido cuando la cola de procesos preparados está
vacía y por tanto no puede realizarse ningún trabajo productivo.

Πc     


El planificador del procesador tiene como misión la asignación del mismo a los procesos que están
en la cola de procesos preparados. Esta cola es alimentada desde dos puntos distintos:

@ Cada vez que un usuario inicie la ejecución de un programa, el planificador a largo plazo recibe la
orden de ejecución, crea el proceso y lo pasa al planificador a corto plazo, colocándose en la cola de
procesos preparados.
@ Cuando un proceso deja de estar en estado de ejecución y no existen causas para su bloqueo, o
deja de estar bloqueado, pasa nuevamente a la cola de procesos preparados.

Por otro lado, cuando un proceso termina su ejecución, deja de existir para el planificador.

Las políticas de planificación se agrupan en:

@ c     Son las que producen un cambio de proceso con cada cambio de contexto;
es decir, el proceso que está haciendo uso del procesador puede ser temporalmente suspendido y
permitir que otro proceso se apropie del procesador. Se utilizan en sistemas operativos con tiempo
compartido y tiempo real.
@ c  
   Son aquellas en las que un proceso no abandona nunca el procesador
desde su comienzo hasta su fin. Se utilizan en sistemas de proceso por lotes.

En los sistemas operativos comerciales existen diversas políticas de planificación, de las cuales
veremos algunas a continuación, puestas en práctica a través de algoritmos que en ningún caso son
perfectos. Recordemos que los objetivos y criterios pueden ser contradictorios entre sí, de manera que si
favorecemos a un tipo de procesos, normalmente perjudicaremos a otros.

Para el estudio de las diferentes políticas nos basaremos en la situación de un grupo de procesos
existentes en un sistema, cuyos datos se encuentran en la Tabla y su representación gráfica en la Figura.

Además de figurar el instante de entrada en el sistema, también se ha representado el tiempo de


servicio de cada proceso, es decir, el tiempo que necesita cada uno de ellos para ejecutarse si fuera el único
presente en el sistema. Por otro lado, supondremos que estos procesos no necesitan realizar operaciones de
entrada/salida (aunque esto sea una utopía) para facilitar el estudio.

c         

En esta política de planificación FCFS (First Come, First Served), el procesador ejecuta cada proceso
hasta que termina; por tanto, los procesos que entren en cola de procesos preparados permanecerán
encolados en el orden en que lleguen hasta que les toque su ejecución (Figura 4.3). Este método se conoce
también como "primero en entrar, primero en salir" (First Input, First Output - FlFO).
Se trata de una política muy simple y sencilla de llevar a la práctica, pero muy pobre en cuanto a su
comportamiento. En la Tabla se muestran los datos de los procesos para esta planificación, y en la Figura
puede verse cómo despacha FCFS los procesos del ejemplo propuesto, donde las partes sombreadas indican
el tiempo que ha estado cada proceso en espera de acceder al procesador.

Podemos observar que el índice de servicio mejora cuantos más largos son los procesos. Es decir,
los procesos cortos que entren en el sistema después de uno o varios largos tendrán que esperar un período
de tiempo relativamente largo hasta su ejecución.

La cantidad de tiempo de espera de cada proceso depende del número de procesos que se
encuentren en cola en el momento de su petición de ejecución y del tiempo que cada uno de ellos tenga en
uso al procesador, y es independiente de las necesidades de ejecución del propio proceso.

Las características de esta política son las siguientes:

@ No es apropiativa.
@ Es justa, aunque los procesos largos hacen esperar mucho a los cortos.
@ Es una política predecible.
@ El tiempo medio de servicio es muy variable en función del número de procesos y su duración.

^^ ^^

Esta política, cuya traducción podría ser asignación cíclica o planificación en rueda, es una mejora de
la FCFS. Trata de ser más justa en cuanto a la respuesta tanto de los procesos cortos como de los largos.

Consiste en conceder a cada proceso en ejecución un determinado período de tiempo q (quantum),


transcurrido el cual, si el proceso no ha terminado, se le devuelve al final de la cola de procesos preparados,
concediéndose el procesador al siguiente proceso por su correspondiente quantum
Esta interrupción periódica continúa hasta que el proceso termine su ejecución, formando una rueda
de procesos que serán ejecutados cíclicamente hasta que terminen.

La gestión de la cola de procesos preparados se puede realizar de muy diversas maneras, siendo las
más comunes la FIFO o por prioridades, donde los procesos se ordenan según su prioridad.

Variando el parámetro q lograremos tener diferentes comportamientos de esta política, de tal forma que si q
es mayor que el tiempo que necesita para su ejecución el proceso más largo, se convertiría en una política
FCFS. En cambio, si se aproxima a 0, la sobrecarga del sistema será muy grande puesto que la mayor parte
del tiempo se consumiría en cambios de contexto.

Los valores de q varían entre 10 y 100 milisegundos, siendo recomendable que el 80% de los tiempos de
respuesta de los procesos sean inferiores al quantum.

En la Figura puede verse esta planificación para el ejemplo propuesto, con un valor de quantum q = 1, con las
siguientes condiciones:

@ Si un proceso finaliza durante su quantum, inmediatamente se le concede el procesador a otro


proceso, al que se le asigna el quantum completo.
@ Al crearse un proceso y pasar a la lista de procesos preparados, se coloca al final de la lista.
@ Si un proceso comienza su ejecución (creación) en el mismo momento en que un quantum finaliza,
se supondrá que dicho proceso ha llegado a la cola de procesos preparados antes de la finalización
del mencionado quantum.
A continuación se repite la planificación RR para un valor de quantum 3 y con las mismas
condiciones que en el caso anterior. La Tabla y la Figura representan los datos y el gráfico, respectivamente,
del ejemplo propuesto para este valor.

En este caso el tiempo de servicio T se mantiene prácticamente constante. Se puede observar que el
tiempo de espera E crece de acuerdo con el tiempo de ejecución de cada proceso.

Las características de esta política de planificación son:

@ Baja sobrecarga si el cambio de contexto es eficiente y los procesos siempre están en la memoria
principal.

El tamaño óptimo del quantum depende de:

@ El tipo de sistema.
@ Las cargas que vaya a soportar el sistema.
@ El número de procesos en el sistema y su tipo.
@ Es la política más utilizada para tiempo compartido.
@ Ofrece un índice de servicio uniforme para todos los procesos. Es una política apropiativa.

      

Hemos visto que la política RR mantiene constante el índice de servicio de los procesos cortos
basándose en la apropiación del procesador. El método SJN (Shortest Job Next) es una política de
planificación no apropiativa que trata de cubrir los mismos objetivos que la RR.

Esta política toma de la cola de procesos preparados el que necesite menos tiempo de ejecución
para realizar su trabajo. Para ello debe saber el tiempo de procesador que necesita cada proceso, lo cual es
tarea nada fácil, pero posible a través de diversos métodos como pueden ser la información suministrada por
el propio usuario, por el propio programa, basándose en la historia anterior (heurística), etc.

El tiempo de servicio T en esta política es bueno para los procesos cortos, saliendo perjudicados los
procesos largos.
En la Figura y la Tabla pueden verse el gráfico y los datos, respectivamente, del ejemplo propuesto
en esta política.

Las características de esta política de planificación son las siguientes:

@ No es apropiativa.
@ El tiempo de espera aumenta de acuerdo con la longitud de los procesos, pero el tiempo medio de
espera con respecto a otras políticas es óptimo.
@ Es poco predecible.
@ No es justa con los procesos largos.
@ Buen tiempo de servicio.
@ Resulta difícil de poner en práctica por los datos que necesita para realizarse la planificación.

c       ^£

La política SRT es una mezcla de los 2 métodos anteriores y trata de obtener las ventajas de ambos.
Para ello esta técnica cambia el proceso que está en ejecución cuando se ejecuta un proceso, con exigencia
de tiempo de ejecución total menor que el que se está ejecutando en el procesador. El valor del tiempo de
respuesta medio de los procesos largos mejora con respecto a SJN.

Esta política presenta las siguientes características

@ Es una variante de SJN, para hacerla apropiativa.


@ Puede ser injusta ya que un proceso corto puede echar a uno largo que esté haciendo uso del
procesador y que además esté terminando.
@ Presenta una mayor sobrecarga.
@ Excelente tiempo medio de servicio
@ Muy eficiente

c   

En esta política se asocia a cada proceso una prioridad, de manera que el procesador se asigna al
proceso de mayor prioridad.
Las prioridades pueden ser definidas interna o externamente. En el primer caso, el sistema operativo
se basa en una serie de informaciones medibles para el cálculo y asignación de dichas prioridades (tiempo
necesitado de procesador, necesidad de memoria, etc.).

El principal problema de esta política es el bloqueo o postergación indefinida, ya que un proceso de


baja prioridad puede estar esperando su turno indefinidamente. Para evitarlo se suele emplear lo que se
denomina envejecimiento de las prioridades, que aumenta gradualmente las prioridades de los procesos que
están a la espera de utilizar el procesador.

Cualquier algoritmo basado en esta política puede ser apropiativo o no apropiativo. En el primer caso,
un proceso puede ser retirado del procesador si aparece otro de mayor prioridad en la cola de procesos
preparados.

El comportamiento de esta política como apropiativa puede verse gráficamente, para el ejemplo
propuesto, en la Figura, y los datos en la Tabla

   

Cuando los procesos que van a ser ejecutados en una computadora se pueden agrupar en distintos
grupos, podemos asignarlos a diferentes colas, cada una con distinta planificación, para darle a cada una de
ellas la que realmente necesita.

Esta política divide a la cola de procesos preparados en varias colas separadas, de manera que los
procesos se asignan a una determinada cola según sus necesidades y tipo.

Para determinar en cada caso qué colase las que suministrara un proceso para que acceda al
procesador cuando este deje a otro anterior, será controlada por un algoritmo de planificación entre las colas,
que normalmente es apreciativo de prioridad fija.
c        

En un sistema multiprogramado con un único procesador, los procesos se intercalan en el tiempo aparentando
una ejecución simultánea. Aunque no se logra un procesamiento paralelo y produce una sobrecarga en los
intercambios de procesos, la ejecución intercalada produce beneficios en la eficiencia del procesamiento y en
la estructuración de los programas.

La intercalación y la superposición pueden contemplarse como ejemplos de procesamiento concurrente en un


sistema monoprocesador, los problemas son consecuencia de la velocidad de ejecución de los procesos que
no pueden predecirse y depende de las actividades de otros procesos, de la forma en que el sistema
operativo trata las interrupciones surgen las siguientes dificultades:

@ Compartir recursos globales es riesgoso


@ Para el sistema operativo es difícil gestionar la asignación óptima de recursos’

Las dificultades anteriores también se presentan en los sistemas multiprocesador.

El hecho de compartir recursos ocasiona problemas, por esto es necesario proteger a dichos recursos.

Los problemas de concurrencia se producen incluso cuando hay un único procesado

c   

El paralelismo, supone la ejecución simultanea de varios procesos. Para implementar el paralelismo se


necesita u hardware adecuado (se necesita de varios procesadores). En caso de tener un único procesador,
se puede simular mediante una ejecución entrelazada y si el sistema es suficientemente rápido el usuario no
se entera. El paralelismo indica ejecución simultánea, por lo tanto, es un caso concreto de concurrencia. Se
pueden sacar las siguientes conclusiones

@ El paralelismo es un caso particular de la concurrencia


@ Sin embargo, concurrencia no implica paralelismo.
@ El paralelismo requiere un soporte físico: varios procesadores.
@ La concurrencia es el caso general y el paralelismo un caso particular.
@ La concurrencia (y el paralelismo) se refiere a la ejecución de código:
Se habla de m    cuando ocurre la ejecución simultánea de instrucciones:
 arquitecturas paralelas
 procesamiento paralelo
 algoritmos paralelos
 programación paralela

Existen varios tipos de paralelismo, como son:

@ Paralelismo independiente: no existe sincronización explícita entre los procesos. Cada uno
representa una aplicación o trabajo separado e independiente. Un uso clásico de este tipo de
paralelismo de dan en sistemas de tiempo compartido.
@ Paralelismo de grano grueso y muy grueso: existe una sincronización entre los procesos pero a un
nivel muy burdo. Este tipo de situación se maneja fácilmente con un conjunto de procesos
concurrentes ejecutando en un monoprocesador multiprogramado y puede verse respaldado por un
multiprocesador con escasos cambios o incluso ninguno en el software del usuario.
@ Paralelismo de grano fino: significa un uso del paralelismo mucho más complejo que el que se
consigue con el uso de hilos. Si bien gran parte del trabajo se realiza en aplicaciones muy paralelas,
este es un campo, hasta el momento, muy especializado y fragmentado, con varias soluciones
diferentes.


!      

3  
 
   


1) El sistema operativo debe seguir a los distintos procesos activos


2) El sistema operativo debe asignar y retirar los distintos recursos a cada proceso activo, entre estos se
incluyen:
@ Tiempo de procesador
@ Memoria
@ Archivos
@ Dispositivos de E/S
3) El sistema operativo debe proteger los datos y los recursos físicos de cada proceso contra injerencias no
intencionadas de otros procesos.

4) Los resultados de un proceso deben ser independientes de la velocidad a la que se realiza la ejecución de
otros procesos concurrentes.

Para abordar la independencia de la velocidad debemos ver las formas en las que los procesos interactúan.

    c 

Se puede clasificar los en que interactúan los procesos en función del nivel de conocimiento que cada proceso
tiene de la existencia de los demás. Existen tres niveles de conocimiento:

1) Los procesos no tienen conocimiento de los demás: son procesos independientes que no operan juntos. Ej:
la multiprogramación de procesos independientes. Aunque los procesos no trabajen juntos, el sistema
operativo se encarga de la "Êm 
Ê  por los recursos.

2) Los procesos tienen un conocimiento indirecto de los otros: los procesos no conocen a los otros por sus
identificadores de proceso, pero muestran cooperación el objeto común.

3) Los procesos tienen conocimiento directo de los otros: los procesos se comunican por el identificador de
proceso y pueden trabajar conjuntamente’
À  
 
 



Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso; dos o más
procesos necesitan acceder a un recurso durante su ejecución .Cada proceso debe dejar tal y como esté el
estado del recurso que utilice.

La ejecución de un proceso puede influir en el comportamiento de los procesos que compiten. Por Ej. Si dos
procesos desean acceder a un recurso, el sistema operativo le asignará el recurso a uno y el otro tendrá que
esperar.

Cuando hay procesos en competencia, se deben solucionar tres problemas de control: la necesidad de
exclusión mutua. Suponiendo que dos procesos quieren acceder a un recurso no compartible. A estos
recursos se les llama "recursos críticos" y la parte del programa que los utiliza es la "sección crítica´ del
programa. Es importante que sólo un programa pueda acceder a su sección crítica en un momento dado.

Hacer que se cumpla la exclusión mutua provoca un interbloqueo.

Otro problema es la inanición si tres procesos necesitan acceder a un recurso, P1 posee al recurso, luego lo
abandona y le concede el acceso al siguiente proceso P2, P1 solicita acceso de nuevo y el sistema operativo
concede el acceso a P1 YP2 alternativamente, se puede negar indefinidamente a P3 el acceso al recurso.

El control de competencia involucra al sistema operativo, porque es el que asigna los recursos.

@ Cooperación entre procesos por compartimiento

Comprende los procesos que interactúan con otros sin tener conocimiento explícito de ellos. Ej. : Varios
procesos pueden tener acceso a variables compartidas.

Los procesos deben cooperar para asegurar que los datos que se comparten se gestionan correctamente. Los
mecanismos de control deben garantizar la integridad de los datos compartidos.

@ Cooperación entre procesos por comunicación

Los distintos procesos participan en una labor común que une a todos los procesos.

La comunicación sincroniza o coordina las distintas actividades, está formada por mensajes de algún tipo. Las
primitivas para enviar y recibir mensajes, vienen dadas como parte del lenguaje de programación o por el
núcleo del sistema operativo

     
Si una actividad desea impedir que otra acceda a ciertos datos compartidos, mientras no se cumpla una
determinada condición, debemos sincronizar las actividades con dicha condición. Por tanto, la sincronización
es un elemento necesario para asegurar la exclusión mutua.

Los algoritmos que se han diseñado para este fin se clasifican:

    

Son aquellos algoritmos que basan todo su funcionamiento en establecer la espera de entrada a la sección
crítica con un bucle que será roto en el momento en que se cumpla una determinada condición. Se llaman de
espera activa por que el proceso no queda bloqueado durante su ejecución, si no que estará compitiendo con
el procesador constantemente. Fueron los primeros motivos en utilizarse y han sido sustituidos por otros más
eficientes.
@    : Algoritmo que utiliza un switch (MUTEX) a través del cual se produce la
sincronización.
@ Π  
Ligeramente mejor que el anterior, utiliza también una variable TURNO para realizar el
sincronismo entre procesos.
@ Π""^
Resuelve el problema mediante la solución propuesta por Dekker,, basando su
funcionamiento en una tabla unidimensional de dos elementos lógicos.(Switches)

    

Son aquellos algoritmos que establecen la espera para entrar en la sección crítica bloqueando el
proceso, haciendo que deje de competir por el procesador hasta que se cumpla la condición de desbloqueo.
Entre los algoritmos existentes citaremos los siguientes:

@   
Para eliminar los problemas que se producen con los algoritmos de espera activa,
fundamentalmente los referidos a la sobrecarga que producen en el sistema, E.W. Dijkstra(1965)
diseño un mecanismo basado en una variable de entrada utilizada como contador de peticiones de
entrada a una sección critica. Esta variable es compartida por todos los procesos del sistema. Este
nuevo tipo de variable se denomina   por su capacidad de gestionar el tráfico de procesos
que deseen acceder a datos compartidos. Con este sistema, cuando un proceso intente entrar a una
sección critica mientras otro esta accediendo a los datos compartidos, se bloqueará de igual manera
que cuando un proceso accede a un recurso que está ocupado.
@ ^   
Son sistemas que permiten establecer protecciones contra una mala utilización
de los usuarios. Para ello solo permiten que datos compartidos puedan acceder desde determinadas
regiones quedando transparentes desde el resto. Tiene pequeños inconvenientes relacionados con la
sincronización y no permite que varias actividades puedan realizar operaciones de lectura
simultánea.
@ ^      
Consiste en una mejora del método anterior tratando de resolver
algunos problemas de sincronización que se presentaban.
@ 0  
Uno de los problemas existentes en los mecanismos anteriores es que el programador
tiene que proporcionar de forma explícita el modo de sincronización. Para evitarlo, B. Hansen y
C.A.R Hoare desarrollaron un nuevo mecanismo denominado 0  , que debe ser soportado por
el lenguaje correspondiente. Un monitor permite compartir, segura y eficientemente, datos entre
actividades garantizando la exclusión mutua, sin necesidad de que el programador tenga que
suministrarla explícitamente. Se basa en dos primicias: La primera es la abstracción de datos
consistente en una técnica capaz de separar las operaciones a ejecutar los datos, de los detalles de
diseño propio de los mismos. La segunda es que realizan la exclusión mutua en forma implícita. La
finalidad más útil de los monitores es reunir todas las funciones que operan sobre un conjunto de
datos compartidos en un solo modulo, de manera que todos los accesos a esos datos estarán
forzados a utilizar dichas funciones.
@      
Es un mecanismo para sincronizar actividades sin que sea necesario
forzar la exclusión mutua, ya sea porque no deseamos limitar la concurrencia de las actividades o
simplemente porque no la necesitemos. Se basa en una variable cuya misión es contar determinadas
operaciones.

@ 0 
Es un mecanismo que permite a los procesos intercambiar aquella información que sea
necesaria durante el desarrollo normal de su ejecución. Por tanto es más un mecanismo de
cooperación y sincronización. Esta cooperación se realiza por medio de mensajes que se envían
entre sí los procesos. Se basa en una zona de memoria compartida que gestiona el S.O.
directamente y que permanece oculta a los procesos. De esta manera el proceso que envía un
mensaje a otro deposita la información en la zona de memoria compartida y el receptor lo lee de ella
posteriormente. En este sistema las directrices de envío y recepción establecen una sincronización
entre los procesos al tener que esperar dichos mensajes, antes de continuar su ejecución.

Existen 2 tipos de comunicación de procesos:


@  
Los procesos se envían y reciben los mensajes directamente entre sí, de manera
que se asocia un enlace bidireccional único entre cada proceso.
@  
 Los mensajes son enviados y recibidos a través de  o  
 . Con este método cada proceso puede estar relacionado con tantos buzones como
desee consiguiendo comunicarse con tantos procesos como sea necesario.

@ !     
El paso de un proceso a otro es un mecanismo muy utilizado para resolver los
problemas de concurrencia entre procesos. Es análogo al paso de os parámetros en una llamada a
una rutina o procedimiento. Si unimos los conceptos de mensajes y paso de parámetros tendremos
lo que se conoce como         creándose una copia del mismo cada
vez que son ejecutadas (      siendo dicha ejecución concurrente. Este tipo de
interacción asegura que hasta que un proceso no termine determinadas operaciones, el siguiente
permanecerá en espera.
@ ^-
Es la culminación de todos los mecanismos anteriores, tratándose de una ligera
modificación del método de las llamadas remotas, donde la llamad, en lugar de ser a todo un
procedimiento, lo es solamente a un grupo de sentencias dentro de él. De igual forma, se trata de un
procedimiento similar al monitor, pero con más versatilidad y potencia. Este método se ha llevado a
la práctica con el lenguaje Ada.

Mecanismos hardware

Son instrucciones hardware que aseguran la exclusión mutua. Entre las más utilizadas citaremos las
siguientes:

@ #       


Las computadoras actuales permiten que las interrupciones pueden
ser deshabilitadas, de esta forma, si un dispositivo generase una interrupción estando deshabilitada,
el reconocimiento y tratamiento de la nueva interrupción se retendrá hasta que se habiliten de nuevo
las interrupciones. Por este medio, se puede forzar la exclusión mutua deshabilitando las
interrupciones mientras haya alguna actividad en la sección crítica. De este modo, dicha actividad no
podrá ser interrumpida y por tanto no se podrá producir ningún cambio de proceso. Normalmente la
deshabilitación y nueva habilitación de las interrupciones suele hacerse con una instrucción máquina,
por lo que resulta ser una operación muy rápida.
@    ££Œ£
Muchas de las computadoras actuales suministran una instrucción
máquina denominada Test and Set, cuya misión es la de forzar la exclusión mutua. La ventaja de
este mecanismo es que no puede ser interrumpida por ser una instrucción del hardware y el
inconveniente es que no son muchas las computadoras que la poseen. Esta instrucción, por sí sola,
no basta para asegurar la exclusión mutua, por lo que tendremos que basarnos en ella para construir
los denominados locks.
@ ! "
Se basa en la instrucción anterior y su cometido es permitir el acceso a la sección crítica a un
proceso en caso de no existir otra actividad dentro de su sección critica, no permitiéndolo en caso
contrario. En este caso, el número de actividades y de procesadores compartiendo memoria principal
puede ser cualquiera, y además son mecanismos simples y fáciles de probar.

 0  
El método más sencillo de comunicación entre los procesos de un programa concurrente es el uso común de
unas variables de datos. El problema de este sistema es que la acción de un proceso interfiere en las
acciones do otro de una forma no adecuada. Para evitar este tipo de errores se pueden identificar aquellas
regiones de los procesos que acceden a variables compartidas y dotarlas de la posibilidad de ejecución como
si fueran una única instrucción. Se denomina sección crítica a aquellas partes de los procesos concurrentes
que no pueden ejecutarse de forma concurrente o, que desde otro proceso se ven como si fueran una única
instrucción. Esto quiere decir que si un proceso entra a ejecutar una sección crítica en la que accede a unas
variables compartidas, entonces otro proceso no puede entrar a ejecutar una

Región crítica en la que se modifique las variables compartidas con el anterior. Las secciones críticas se
pueden agrupar en clases, siendo mutuamente exclusivas las secciones críticas de cada una. Para conseguir
dicha exclusión se deben implementar protocolos software que impidan o bloqueen el acceso a una sección
crítica mientras está siendo utilizada por un proceso.

       

Se usa una variable de tipo booleano llamada ³flag´ que es compartida por los procesos, se asocia a cada
recurso que se comparte. Si el sistema dispone de una instrucción que permita comprobar el estado de la flag
y modificarlo simultáneamente, el programa permitiría el uso del recurso sin entrelazamiento. En caso de usar
dos indicadores para un recurso, puede ocurrir que ambos procesos vean los indicadores contrarios como
ocupados, y permanezcan a la espera de liberación del recurso, pero esto no puede ocurrir al no poder entrar
ninguno en su sección crítica (Interbloqueo o

deadlock).

Se puede intentar resolver el problema haciendo que el proceso desactive su propio indicador durante la fase
de bloqueo siempre que encuentre que el indicador del otro proceso está activado. El algoritmo permite que
en caso de interbloqueo se pueda proseguir siempre que no exista una completa sincronización entre los dos
procesos, ya que en el caso bastante improbable, pero que pudiera darse, de que los dos procesos realicen
exactamente las mismas operaciones a la vez, se encontrarían permanentemente con los indicadores
contrarios activados. Otro problema con este algoritmo es que puede permitir que un proceso deje su sección
crítica y vuelva a entrar mientras que el otro proceso desactiva su indicador en la sección de bloqueo.

El que un proceso no pueda progresar porque se lo impida otro proceso o grupo de procesos se denomina
cierre (lockout o starvation). Veamos ahora dos soluciones al problema de la exclusión mutua que evitan el
interbloqueo y el cierre.

Π 
   

Una posible solución es introducir una variable adicional, denominada 


 (Peterson, 1981), que sólo resulta
útil cuando se produzca un problema de petición simultánea de acceso a la región crítica:

(* Exclusión mutua; Solución de Peterson *)

Exclusion_ Mutua_ P;

 flag1, flag2: Boolean;

turno : integer;

c  bloqueo ( mi_flag, su_flag: boolean; su_turno:integer);

 

mi_flag: = true;

turno : = su_turno;

$# su_flag and (turno : = su_turno) ; 

bloqueo;

c  desbloqueo ( mi_falg: boolean);

 
mi_flag : = false;

end desbloqueo;

 P1

 



bloqueo(flag1, flag2, 2);

(* Uso del recurso Sección Crítica *)

desbloqueo (flag1);

(* Resto del proceso *)

%

P1;

 P2

 



bloqueo(flag2, flag1, 1);

(* Uso del recurso Sección Crítica *)

desbloqueo (flag2);

(* Resto del proceso *)

%

P2;

 (* Exclusión_ Mutua_ P *)

flag1 : = false

flag2 : = false;

 

P1;

P2;



Exclusión_ Mutua_ P.

Si sólo uno de los procesos intenta acceder a la sección crítica lo podrá hacer sin ningún problema. Sin
embargo, si ambos intentan entrar a la vez, el valor del turno se pondrá a 1 y 2 pero sólo un valor de ellos
permanecerá al escribirse sobre el otro, permitiendo el acceso de un proceso a su región crítica. El algoritmo
permite resolver el problema de exclusión mutua y garantiza que ambos procesos usarán de forma
consecutiva el recurso en el caso de que lo utilicen a la vez y se impedirá el cierre del otro proceso.

Π    

Utiliza también una variable de turno, que sirve para establecer la prioridad relativa de los dos procesos y
actúa en la sección crítica, lo que evita posibles interferencias entre procesos:

(*Exclusión mutua: Solución de Dekker *)

Exclusion_Mutua_D;

 flag1, flag2: Boolean;

turno : integer;

c  bloqueo ( mi_flag, su_flag: boolean; su_turno:integer);

 

mi_flag: = true;

$# su_flag (* otro proceso en la sección crítica*)

turno = su_turno #

mi_flag : = false;

$# turno = su_turno 

; (*espera que el otro acabe*)

;

mi_flag : = true;

%

%

bloqueo;

c  desbloqueo ( mi_falg: boolean; su_turno :integer);

 

turno : = su_turno

mi_flag : = false;

desbloqueo;

 P1

 



bloqueo(flag1, flag2, 2);

(* Uso del recurso Sección Crítica *)


desbloqueo (flag1,2);

(* Resto del proceso *)

%

P1;

 P2

 



bloqueo(flag2, flag1, 1);

(* Uso del recurso Sección Crítica *)

desbloqueo (flag2,1);

(* Resto del proceso *)

%

P2;

 (* Exclusión_Mutua_D *)

flag1 : = false

flag2 : = false;

turno : =1;

 

P1;

P2;



Exclusión_Mutua_D.

El programa se inicia con el valor de turno 1, lo que da prioridad al proceso P1. Si ambos programas piden a
la vez el acceso a su sección crítica, activan sus respectivos indicadores y comprueban si el indicador del otro
está activado.

Ambos encuentran que sí, por lo que pasan a evaluar el turno. El segundo encuentra que no es su turno,
desactiva su indicador y se queda en espera de que lo sea. P1 comprueba que si es su turno, entra en su
región crítica y dará el turno a P2 antes de desactivar su indicador.

Los algoritmos de Peterson y Dekker se pueden extender al caso más general con
procesos en ejecución
concurrente; pero no son soluciones adecuadas ya que la espera de acceso a un recurso siempre se realiza
de forma ³ocupada´. El proceso se queda permanente comprobando una variable, lo que puede suponer un
derroche de los recursos del sistema.


  &  

La exclusión mutua necesita ser aplicada solo cuando un proceso acceda a datos compartidos; cuando los
procesos ejecutan operaciones que no estén en conflicto entre si, debe permitírseles proceder de forma
concurrente. Cuando un proceso esta accesando datos se dice que el proceso se encuentra en su sección
critica ( o región critica).

Mientras un proceso se encuentre en su sección crítica, los demás procesos pueden continuar su ejecución
fuera de sus secciones críticas. Cuando un proceso abandona su sección critica, entonces debe permitírsele
proceder a otros procesos que esperan entrar en su propia sección crítica (si hubiera un proceso en espera).
La aplicación de la exclusión mutual es uno de los problemas clave de la programación concurrente. Se han
diseñado muchas soluciones para esto: algunas de software y algunas de hardware, más de bajo nivel y otras
de alto nivel; algunas que requieren de cooperación voluntaria, y algunas que demandan una adherencia
rígida a protocolos estrictos.

Estar dentro de una sección crítica es un estado muy especial asignado a un estado. El proceso tiene acceso
exclusivo a los datos compartidos, y todos los demás procesos que necesitan accesar a esos datos
permanecen en espera. Por tanto, las secciones críticas deben ser ejecutadas lo más rápido posible, un
programa no debe bloquearse dentro de su sección crítica, y las secciones críticas deben ser codificadas con
todo cuidado.

Si un proceso dentro de una sección crítica termina, tanto de forma voluntaria como involuntaria, entonces, al
realizar su limpieza de terminación, el sistema operativo debe liberar la exclusión mutua para que otros
procesos puedan entrar en sus secciones críticas


0  

En la programación paralela, los    son objetos destinados a ser usados sin peligro por más de un
hilo de ejecución. La característica que principalmente los define es que sus métodos son ejecutados con
exclusión mutua. Lo que significa, que en cada momento en el tiempo, un hilo como máximo puede estar
ejecutando cualquiera de sus métodos. Esta exclusión mutua simplifica el razonamiento de implementar
monitores en lugar de código a ser ejecutado en paralelo.

En el estudio y uso de los semáforos se puede ver que las llamadas a las funciones necesarias para utilizarlos
quedan repartidas en el código del programa, haciendo difícil corregir errores y asegurar el buen
funcionamiento de los algoritmos. Para evitar estos inconvenientes se desarrollaron los monitores. El concepto
de monitor fue definido por primera vez por Charles Antony Richard Hoare en un artículo del año 1974. La
estructura de los monitores se ha implementado en varios lenguajes de programación, incluido Pascal
concurrente, Modula-2, Modula-3 y Java, y como biblioteca de programas.

À  

Un monitor tiene cuatro componentes: inicialización, datos privados, procedimientos del monitor y cola de
entrada.

@ Inicialización: contiene el código a ser ejecutado cuando el monitor es creado


@ Datos privados: contiene los procedimientos privados, que sólo pueden ser usados desde 
 del
monitor y no son visibles desde fuera
@ Procedimientos del monitor: son los procedimientos que pueden ser llamados desde  del
monitor.
@ Cola de entrada: contiene a los hilos que han llamado a algún procedimiento del monitor pero no han
podido adquirir permiso para ejecutarlos aún.

       


Los monitores están pensados para ser usados en entornos multiproceso o multihilo, y por lo tanto muchos
procesos o threads pueden llamar a la vez a un procedimiento del monitor. Los monitores garantizan que en
cualquier momento, a lo sumo un thread puede estar ejecutando 
 de un monitor. Ejecutar dentro de un
monitor significa que sólo un thread estará en estado de ejecución mientras dura la llamada a un
procedimiento del monitor. El problema de que dos threads ejecuten un mismo procedimiento dentro del
monitor es que se pueden dar condiciones de carrera, perjudicando el resultado de los cálculos. Para evitar
esto y garantizar la integridad de los datos privados, el monitor hace cumplir la exclusión
mutua &  , de modo que sólo un procedimiento esté siendo ejecutado a la vez. De esta forma, si
un thread llama a un procedimiento mientras otro thread está dentro del monitor, se bloqueará y esperará en
la cola de entrada hasta que el monitor quede nuevamente libre. Aunque se la llama cola de entrada, no
debería suponerse ninguna política de encolado.

Para que resulten útiles en un entorno de concurrencia, los monitores deben incluir algún tipo de forma de
sincronización. Por ejemplo, supóngase un thread que está dentro del monitor y necesita que se cumpla una
condición para poder continuar la ejecución. En ese caso, se debe contar con un mecanismo de bloqueo del
thread, a la vez que se debe liberar el monitor para ser usado por otro hilo. Más tarde, cuando la condición
permita al thread bloqueado continuar ejecutando, debe poder ingresar en el monitor en el mismo lugar donde
fue suspendido. Para esto los monitores poseen       que son accesibles sólo desde
adentro. Existen dos funciones para operar con las variables de condición:

@ cond_wait(c): suspende la ejecución del proceso que la llama con la condición Ê. El monitor se
convierte en el dueño del lock y queda disponible para que otro proceso pueda entrar
@ cond_signal(c): reanuda la ejecución de algún proceso suspendido con Ê
 bajo la misma
condición Ê. Si hay varios procesos con esas características elige uno. Si no hay ninguno, no hace
nada.

Nótese que, al contrario que los semáforos, la llamada a Ê


 
Ê se pierde si no hay tareas esperando
en la variable de condición Ê.

Las variables de condición indican eventos, y no poseen ningún valor. Si un thread tiene que esperar que
ocurra un evento, se dice espera por (o en) la variable de condición correspondiente. Si otro thread provoca
un evento, simplemente utiliza la función Ê
 
 con esa condición como parámetro. De este modo, cada
variable de condición tiene una cola asociada para los threads que están esperando que ocurra el evento
correspondiente. Las colas se ubican en el sector de datos privados visto anteriormente.

La política de inserción de procesos en las colas de las variables condición es la FIFO, ya que asegura que
ningún proceso caiga en la espera indefinida, cosa que sí ocurre con la política LIFO (puede que los procesos
de la base de la pila nunca sean despertados) o con una política en la que se desbloquea a un proceso
aleatorio.

£    

Antes se dijo que una llamada a la función Ê


 
 con una variable de condición hacía que un proceso
que estaba esperando por esa condición reanudara su ejecución. Nótese que el thread que reanuda su
ejecución necesitará obtener nuevamente el lock del monitor. Surge la siguiente pregunta: ¿qué sucede con el
thread que hizo el Ê
 
? ¿pierde el lock para dárselo al thread que esperaba? ¿qué thread continúa
con su ejecución? Cualquier solución debe garantizar la exclusión mutua. Según quién continúa con la
ejecución, se diferencian dos tipos de monitores: [  y 0 .

£  


3 




  Ê   
 3 

      
 
 


 
   

Ventajas:
@ El thread que reanuda la ejecución puede hacerlo inmediatamente sin fijarse si la condición se
cumple, porque desde que se ejecutó Ê
 
 hasta que llegó su turno de ejecutar ningún
proceso puede cambiarla.
@ El thread despertado ya estaba esperando desde antes, por lo que podría suponerse que es más
urgente ejecutarlo a seguir con el proceso despertante.

Desventajas:

@ Si el proceso que ejecuta Ê


 
 no terminó con su ejecución se necesitarán dos cambios de
contexto para que vuelva a tomar el lock del monitor.
@ Al despertar a un thread que espera en una variable de condición, se debe asegurar que reanude su
ejecución inmediatamente. De otra forma, algún otro thread podría cambiar la condición. Esto implica
que la planificación debe ser muy fiable, y dificulta la implementación.

£ 0 

Butler W. Lampson y David D. Redell en 1980 desarrollaron una definición diferente de monitores para el
lenguaje Mesa que lidia con las desventajas de los monitores de tipo Hoare y añade algunas características.

En los monitores de Lampson y Redell el thread que ejecuta Ê


 
 sobre una variable de condición
continúa con su ejecución dentro del monitor. Si hay otro thread esperando en esa variable de condición, se lo
despierta y deja como listo. Podrá intentar entrar el monitor cuando éste quede libre, aunque puede suceder
que otro thread logre entrar antes. Este nuevo thread puede cambiar la condición por la cual el primer thread
estaba durmiendo. Cuando reanude la ejecución el durmiente, debería verificar que la condición efectivamente
es la que necesita para seguir ejecutando. En el proceso que durmió, por lo tanto, es necesario cambiar la
instrucción  por × , para que al despertar compruebe nuevamente la condición, y de no ser cierta vuelva a
llamar a Ê
 .

Además de las dos primitivas Ê


 Ê y Ê
 
Ê , los monitores de Lampson y Redell poseen la
función Ê
 Ê  Ê , que notifica a los threads que están esperando en la variable de condición Ê y los
pone en estado listo. Al entrar al monitor, cada thread verificará la condición por la que estaban detenidos, al
igual que antes.

Los monitores del tipo Mesa son menos propensos a errores, ya que un thread podría hacer una llamada
incorrecta a Ê
 
 o a Ê
 Ê  sin afectar al thread en espera, que verificará la condición y
seguirá durmiendo si no fuera la esperada.

  
Es una solución sencilla y elegante del problema de la exclusión mutua. Esta técnica permite solucionar la
mayoría de los problemas de sincronización entre procesos. Un semáforo binario es un indicador de condición
(s) que registra si un registro está disponible o no. Un semáforo sólo puede tomar dos valores; 0 y 1. Si para
un semáforo, S=1 el recurso está disponible y la tarea lo puede utilizar; si S=0 el recurso no está disponible y
el proceso debe esperar.

Los semáforos se implementan mediante una cola de tareas a la que se añaden los procesos que están en
espera del recurso. Solo se permiten tres operaciones sobre un semáforo:

1.     (s: Semáforo_Binario; v: integer) -- > poner el valor del semáforo s al valor de v (0,1).
2.  $ (s) s = 1 #s: = 0 Suspender la tarea que hace la llamada y ponerla en la cola
de tareas.
3. '   (s) cola de tareas vacía #s : = 1 Reanudar la primera tarea de la cola
tareas.
Estas operaciones son procedimientos que se implementan como acciones indivisibles. En sistemas con un
único procesador bastará simplemente con inhibir las interrupciones durante la ejecución de las operaciones
del semáforo. Al introducir el semáforo se crea un nuevo estado en el diagrama de transiciones, el de espera.

c^ c!£^!()

El interbloqueo se puede definir como el bloqueo permanente de un conjunto de procesos que compiten por
los recursos del sistema o bien se comunican unos con otros. A diferencia de otros problemas de la gestión
concurrente de procesos, no existe una solución eficiente para el caso general.

Todos los interbloqueos suponen necesidades contradictorias de recursos por parte de dos o más procesos.

 
 

 
   

Cuatro coches llegan aproximadamente en el mismo instante a un cruce de cuatro caminos. Los cuatro
cuadrantes de la intersección son los recursos compartidos sobre los que se demanda control; por tanto, si los
coches desean atravesar el cruce, las necesidades de recursos son las siguientes:

@ El coche que va hacia el norte necesita los cuadrantes 1 y 2.


@ El coche que va hacia el oeste necesita los cuadrantes 2 y 3.
@ El coche que va hacia el sur necesita los cuadrantes 3 y 4.
@ El coche que va hacia el este necesita los cuadrantes 4 y 1.
La norma más habitual en la carretera es que un coche en un cruce de cuatro caminos debe ceder el paso al
coche que está a su derecha. Esta norma funciona si solo hay dos o tres coches en el cruce. Por ejemplo, si
solo llegan al cruce los coches del norte y del oeste, el coche del norte esperará hasta que el del oeste pase.
Sin embargo, si los cuatro coches llegan al mismo tiempo cada uno se abstendrá de entrar en el cruce,
provocando interbloqueo. Si todos los coches ignoran las normas y entran (con cuidado) en el cruce, cada
coche obtendrá un recurso (un cuadrante) pero no podrá continuar porque el segundo recurso que necesita ya
ha sido invadido por otro coche. De nuevo, se tiene interbloqueo.

 *: Cruce en un puente (es parecido al interbloqueo de trafico)

En una carretera de dos direcciones, donde en un determinado cruce con la vía del ferrocarril, se ha
construido un puente que solo deja pasar vehículos en un solo sentido. El bloqueo ocurre cuando dos carros
intentan pasar por el puente al mismo tiempo.

Una manera de resolver el bloqueo es: el conductor situado en uno de los extremos es lo suficientemente
educado que deja pasar en primer lugar al del otro extremo y luego pasa él.

Este ejemplo nos muestra como sucede el interbloqueo en nuestra vida diaria.

 

Dos procesos desean imprimir cada uno un enorme archivo en cinta. El proceso Πsolicita el permiso para
utilizar la impresora, el cual se le concede. Es entonces cuando el proceso  solicita permiso para utilizar la
unidad de cinta y se le otorga. El proceso Πsolicita entonces la unidad de cinta, pero la solicitud es denegada
hasta que  la libere. Por desgracia, en este momento, en vez de liberar unidad de cinta,  solicita la
impresora. Los procesos se bloquean en ese momento y permanecen así por siempre’

 

Un sistema se compone de un numero finito de recursos que se distribuyen entre varios tipos:

@ Físicos: Ciclo de cpu, espacio en memoria, dispositivos de e/s (impresoras, unidades de cinta, etc.)
@ Lógicos: Ficheros, tablas del sistema, semáforos.

Por lo general, una computadora tiene distintos recursos que pueden ser otorgados. Algunos recursos podrán
tener varias instancias idénticas, como es el caso de tres unidades de cinta. Si se tienen disponibles varias
copias de un recurso, cualquiera de ellas se pude utilizar para satisfacer cualquier solicitud del recurso. Un
recurso es cualquier cosa que solo puede ser utilizada por un único proceso en un instante dado.

Los recursos son de dos tipos:

@ Apropiable
@ No apropiables

Un recurso apropiable es aquel que se puede tomar del proceso que lo posee sin efectos dañinos. La
memoria es un ejemplo de recurso apropiable.

Por el contrario, un recurso no apropiable, es aquel que no se puede tomar de su poseedor activo sin provocar
un fallo de calculo. Si un proceso comienza a imprimir una salida, se toma la impresora y se le da a otro
proceso, el resultado será una salida incomprensible. Las impresoras no son apropiables.

Los interbloqueos se relacionan con los recursos no apropiables. Lo usual es que los bloqueos asociados a
recursos apropiables se pueden resolver, mediante la reasignación de recursos de un proceso a otro.

La secuencia de eventos necesaria para utilizar un recurso es:

@ Solicitar el recurso
@ Utilizar el recurso
@ Liberar el recurso

Si el recurso no esta disponible cuando se le solicita, el proceso solicitante debe esperar. En algunos
sistemas operativos, el proceso se bloquea de manera automática al fallar una solicitud de un recurso y se
despierta cuando dicho recurso esta disponible.

En otros sistemas la solicitud falla con un código de error y el proceso solicitante debe esperar un poco e
intentar de nuevo.

Un proceso cuya solicitud de un recurso ha sido denegada entra por lo general en un ciclo, en el cual solicita
el recurso, duerme e intenta de nuevo.

Aunque este proceso no esta bloqueado, para todos los efectos esta como bloqueado, puesto que no puede
hacer ninguna labor útil.

El interbloque se puede definir entonces de la siguiente forma:

Un conjunto de procesos se encuentra en estado de interbloqueo cuando cada uno de ellos espera un suceso
que solo puede originar otro proceso del mismo conjunto.
En la mayoría de los casos, el evento que espera cada proceso es la liberación de cierto recurso que posee
por el momento otro miembro del conjunto. En otras palabras, cada miembro del conjunto de procesos
bloqueados espera un recurso poseído por un proceso bloqueado. Ninguno de los procesos puede continuar
su ejecución, ni liberar recursos, y puede ser despertado.

       


En la política del sistema operativo, deben darse tres condiciones para que pueda producirse un interbloqueo:

1- Condición de exclusión mutua: Cada recurso esta asignado a un único proceso o esta disponible.
2- Condición de posesión y espera: Los procesos que tienen, en un momento dado, recursos
asignados con anterioridad, pueden solicitar nuevos recursos.
3- Condición de no apropiación: Los recursos otorgados con anterioridad no pueden ser forzados a
dejar un proceso. El proceso que los posee debe liberarlos en forma explicita.

En la mayoría de los casos, estas condiciones son bastantes necesarias. La exclusión mutua hace
falta para asegurar la consistencia de resultados y la integridad de la base de datos. De forma
similar, la apropiación no se puede aplicar arbitrariamente y, cuando se encuentran involucrados
recursos de datos, debe estar acompañada de un mecanismo de recuperación y reanulación, que
devuelva un proceso y sus recursos a un estado previo adecuado, desde el que el proceso puede
finalmente repetir sus acciones.

Puede no existir interbloqueo con solo estas tres condiciones. Para que se produzca interbloqueo, se
necesita una cuarta condición:

ë Condición de espera circular (o circulo vicioso de espera): Debe existir una cadena circular de dos o
más procesos, cada uno de los cuales espera un recurso poseído por el siguiente miembro de la
cadena.

Las tres primeras condiciones son necesarias, pero no suficientes, para que exista interbloqueo. La cuarta
condición es, en realidad, una consecuencia potencial de las tres primeras. Es decir, dado que se producen
las tres primeras condiciones, puede ocurrir una secuencia de eventos que desemboque en un circulo vicioso
de espera irresoluble. El circulo de espera de la condición 4 es irresoluble porque se mantienen las tres
primeras condiciones. Las cuatro condiciones en conjunto constituyen una condición necesaria y suficiente
para el interbloqueo’

c    


La estrategia básica de la prevención del interbloqueo consiste, a grandes rasgos, en diseñar su sistema de
manera que esté excluida, a priori, la posibilidad de interbloqueo.

Los métodos para prevenir el interbloqueo son de dos tipos:


6 Los métodos indirectos que consisten en impedir la aparición de alguna de las tres condiciones
necesarias para que se produzca el interbloqueo.
6 Los métodos directos que consisten en evitar la aparición del circulo vicioso de espera.

3 
 
Si ningún recurso se puede asignar de forma exclusiva, no se producirá interbloqueo. Sin embargo, existen
recursos para los que no es posible negar la condición de exclusión mutua. No obstante, es posible eliminar
esta condición en algunos procesos. Por ejemplo, una impresora es un recurso no compatible pues si se
permite que dos procesos escriban en la impresora al mismo tiempo, la salida resulta caótica. Pero con el
spooling de salida varios procesos pueden generar salida al mismo tiempo. Puesto que el spooler nunca
solicita otros recursos, se elimina el bloqueo originado por la impresora.

El inconveniente es que no todos los recursos pueden usarse de esta forma (por ejemplo, la tabla de procesos
no se presenta al spooling y, además, la implementación de esta técnica puede introducir nuevos motivos de
interbloqueo, ya que el spooling emplea una zona de disco finita)

^ 

  
La condición de retención y espera puede prevenirse exigiendo que todos los procesos soliciten todos los
recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los recursos puedan
concederse simultáneamente. Esta solución resulta ineficiente por dos factores:

@ En primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que
concedan todas sus solicitudes de recursos, cuando de hecho podría haber avanzado con solo
algunos de los recursos.
@ Y en segundo lugar, los recursos asignados a un proceso pueden permanecer sin usarse durante
periodos considerables, tiempo durante el cual se priva del acceso a otros procesos.

!  

La condición de no apropiación puede prevenirse de varias formas. Primero, si a un proceso que retiene
ciertos recursos se le deniega una nueva solicitud, dicho proceso deberá liberar sus recursos anteriores y
solicitarlos de nuevo, cuando sea necesario, junto con el recurso adicional. Por otra parte, si un proceso
solicita un recurso que actualmente esta retenido por otro proceso, el sistema operativo debe expulsar al
segundo proceso y exigirle que libere sus recursos. Este último esquema evitará el interbloqueo sólo si no hay
dos procesos que posean la misma prioridad.

Esta técnica es práctica sólo cuando se aplica a recursos cuyo estado puede salvarse y restaurarse más tarde
de una forma fácil, como es el caso de un procesador.

    


La condición del círculo vicioso de espera puede prevenirse definiendo una ordenación lineal de los tipos de
recursos. Si a un proceso se le han asignado recursos de tipo R, entonces sólo podrá realizar peticiones
posteriores sobre los recursos de los tipos siguientes a R en la ordenación.

Para comprobar el funcionamiento de esta estrategia, se asocia un índice a cada tipo de recurso. En tal caso,
el recurso ^ antecede a ^ en la ordenación si < . Entonces, supóngase que dos procesos A y B, están
interbloqueados, porque A ha adquirido ^ y solicitado ^ , mientras que B ha adquirido ^ y solicitado ^ . Esta
condición es imposible porque implica que < y < .

Como en la retención y espera, la prevención del círculo vicioso de espera puede ser ineficiente, retardando
procesos y denegando accesos a recursos innecesariamente

c     

Una forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevención, es la
predicción del interbloqueo. En la prevención de interbloqueo, se obligaba a las solicitudes de recursos a
impedir que sucediera, por lo menos, alguna de las cuatro condiciones de interbloqueo. Esto se hace
indirectamente, impidiendo la aparición de una de las tres condiciones necesarias (exclusión mutua, retención
y espera, no apropiación) o directamente, impidiendo la aparición de un círculo vicioso de espera. Se llega así
a un uso ineficiente de los recursos y una ejecución ineficiente de los procesos. Con predicción del
interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se realizan elecciones
acertadas para asegurar que nunca se llega al punto de interbloqueo. La predicción, por lo tanto, permite más
concurrencia que la prevención.

Con predicción del interbloqueo, se decide dinámicamente si la petición actual de asignación de un recurso
podría, de concederse, llevar potencialmente a un interbloqueo. La predicción del interbloqueo necesita, por lo
tanto, conocer las peticiones futuras de recursos.

Enfoques para la predicción del interbloqueo:

@ No iniciar un proceso si sus demandas pueden llevar a interbloqueo.


@ No conceder una solicitud de incrementar los recursos de un proceso si esta asignación puede llevar
a interbloqueo.