UNIDAD 2.

ADMINISTRACION DE PROCESOS Y PROCESADOR

2.1.CONCEPTO DE PROCESO

Un proceso no es más que un conjunto de threads(hilos) que ejecutan el mismo código, junto con las
zonas de memoria asociadas a ellos y los ficheros que tienen abiertos.
Un programa consta, al menos, de un proceso, y un proceso, al menos, de un thread. Cuando un
programa tiene varios procesos, lo normal es que cada uno ejecute un código distinto, los cuales se
encuentran en ficheros ejecutables separados. Dos procesos solo pueden compartir una zona de
memoria si esta es definida expresamente como tal. Así mismo, es en este caso cuando los sistemas
de sincronización a la hora de compartir memoria (de los que hablaremos más adelante) se vuelven
especialmente necesarios e importantes.

2.2 ESTADOS Y TRANSICIONES DE PROCESOS

Durante su vida, un proceso puede pasar por una serie de estados discretos, algunos de ellos son:

 En ejecución: El proceso ocupa la CPU actualmente, es decir, se está ejecutando.

 Listo o preparado: El proceso dispone de todos los recursos para su ejecución, sólo le falta la
CPU.
 Bloqueado: Al proceso le falta algún recurso para poder seguir ejecutándose, además de la
CPU. Por recurso se pueden entender un dispositivo, un dato, etc. El proceso necesita que
ocurra algún evento que le permita poder proseguir su ejecución.

Hay otros estados de los procesos, pero en la presente exposición se tratarán estos tres. Por
sencillez, se considera un sistema con una sola CPU, aunque no es difícil la extensión a múltiples
procesadores. Solamente puede haber un proceso en ejecución a la vez, pero pueden existir varios
listos y varios pueden estar bloqueados. Así pues, se forman una lista de procesos listos y otra de
procesos bloqueados. La lista de procesos listos se ordena por prioridad, de manera que el siguiente
proceso que reciba la CPU será el primero de la lista. La lista de procesos bloqueados normalmente
no está ordenada; los procesos no se desbloquean (es decir, no pasan a ser procesos listos) en
orden de prioridad, sino que lo hacen en el orden de ocurrencia de los eventos que están esperando.
Como se verá más adelante, hay situaciones en las cuales varios procesos pueden bloquearse
esperando la ocurrencia del mismo evento; en tales casos es común asignar prioridades a los
procesos que esperan.

Transiciones de estado de los procesos

A continuación se dan ejemplos de eventos que pueden provocar transiciones de estado en un
proceso en este modelo de tres estados. La mayoría de estos eventos se discutirán con profundidad
a lo largo del curso:
 De ejecución á Bloqueado: al iniciar una operación de E/S, al realizar una operación WAIT
sobre un semáforo a cero (en el tema de procesos concurrentes se estudiarán los
semáforos).
 De ejecución á Listo: por ejemplo, en un sistema de tiempo compartido, cuando el proceso
que ocupa la CPU lleva demasiado tiempo ejecutándose continuamente (agota su cuanto) el
sistema operativo decide que otro proceso ocupe la CPU, pasando el proceso que ocupaba
la CPU a estado listo.
 De Listo á en ejecución: cuando lo requiere el planificador de la CPU (veremos el planificador
de la CPU en el tema de planificación de procesos).
 De Bloqueado á Listo: se dispone del recurso por el que se había bloqueado el proceso. Por
ejemplo, termina la operación de E/S, o se produce una operación SIGNAL sobre el
semáforo en que se bloqueó el proceso, no habiendo otros procesos bloqueados en el
semáforo.
Obsérvese que de las cuatro transiciones de estado posibles, la única iniciada por el proceso de
usuario es el bloqueo, las otras tres son iniciadas por entidades externas al proceso.

2.3 PROCESOS LIGEROS HILOS O HEBRAS

El concepto de proceso es más complejo y sutil que el presentado hasta ahora. Engloba dos
conceptos separados y potencialmente independientes: uno relativo a la propiedad de recursos y otro
que hace referencia a la ejecución.
 Unidad que posee recursos: A un proceso se le asigna un espacio de memoria y, de tanto en
tanto, se le puede asignar otros recursos como dispositivos de E/S o ficheros.
 Unidad a la que se le asigna el procesador: Un proceso es un flujo de ejecución (una traza) a
través de uno o más programas. Esta ejecución se entremezcla con la de otros procesos. De
tal forma, que un proceso tiene un estado (en ejecución, listo, etc.) y una prioridad de
expedición u origen. La unidad planificada y expedida por el sistema operativo es el proceso.
En la mayoría de los sistemas operativos, estas dos características son, de hecho, la esencia de un
proceso. Sin embargo, son independientes, y pueden ser tratadas como tales por el sistema
operativo. Esta distinción ha conducido en los sistemas operativos actuales a desarrollar la
construcción conocida como thread, cuyas traducciones más frecuentes son hilo, hebra y proceso
ligero. Si se tiene esta división de características, la unidad de asignación de la CPU se conoce como
hilo, mientras que a la unidad que posee recursos se le llama proceso.
Dentro de un proceso puede haber uno o más hilos de control cada uno con:
 Un estado de ejecución (en ejecución, listo, bloqueado).
 Un contexto de procesador, que se salva cuando no esté ejecutándose.
 Una pila de ejecución.
 Algún almacenamiento estático para variables locales.
 Acceso a la memoria y a los recursos de ese trabajo que comparte con los otros hilos.
Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: se tarda menos
tiempo en crear un nuevo hilo de un proceso que ya existe, en terminarlo, y en hacer un cambio de
contexto entre hilos de un mismo proceso. Al someter a un mismo proceso a varios flujos de
ejecución se mantiene una única copia en memoria del código, y no varias.
Un ejemplo de aplicación que podría hacer uso de los hilos es un servidor de ficheros de una red de
área local. Cada vez que llega una solicitud de una operación sobre un fichero, se puede generar un
nuevo hilo para su gestión. El servidor gestiona multitud de solicitudes, por tanto, se pueden crear y
destruir muchos hilos en poco tiempo para dar servicio a estas peticiones. Si el servidor es un
multiprocesador, se pueden ejecutar varios hilos de un mismo proceso simultáneamente y en
diferentes procesadores.

2.4 CONCURRENCIA Y SECUENCIABILIDAD

La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación

entre procesos, comparación y competencia por los recursos, sincronización de la ejecución de varios
procesos y asignación del tiempo de procesador a los procesos y es fundamental para que existan
diseños como Multiprogramación, Multiproceso y Proceso distribuido
Los procesos son concurrentes si existen simultáneamente. Cuando dos o más procesos llegan al
mismo tiempo a ejecutarse, se dice que se ha presentado una concurrencia de procesos. Es
importante mencionar que para que dos o más procesos sean concurrentes, es necesario que tengan
alguna relación entre ellos. La concurrencia puede presentarse en tres contextos diferentes:

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

máquina fuese compartido dinámicamente entre varios trabajos o aplicaciones activas.
• Aplicaciones estructuradas: Como ampliación de los principios del diseño modular y la
programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un
conjunto de procesos concurrentes.
• Estructura del sistema operativo: Las mismas ventajas de estructuración son aplicables a los
programadores de sistemas y se ha comprobado que algunos sistemas operativos están
implementados como un conjunto de procesos. Existen tres modelos de computadora en los que se
pueden ejecutar procesos concurrentes:
• Multiprogramación con un único procesador. El sistema operativo se encarga de ir
repartiendo el tiempo del procesador entre los distintos procesos, intercalando la ejecución de
los mismos para dar así una apariencia de ejecución simultánea.
• Multiprocesador. Es una maquina formada por un conjunto de procesadores que comparten
memoria principal. En este tipo de arquitecturas, los procesos concurrentes no sólo pueden
intercalar su ejecución sino también superponerla.
• Multicomputadora. Es una máquina de memoria distribuida, que está formada por una serie
de computadoras. En este tipo de arquitecturas también es posible la ejecución simultánea de
los procesos sobre los diferentes procesadores.

En general, la concurrencia será aparente siempre que el número de procesos sea mayor que el de
procesadores disponibles, es decir, cuando haya más de un proceso por procesador. La concurrencia
será real cuando haya un proceso por procesador. Aunque puede parecer que la intercalación y la
superposición de la ejecución de procesos presentan formas de ejecución distintas, se verá que
ambas pueden contemplase como ejemplos de procesos concurrentes. Existen diversas razones que
motivan la ejecución de procesos concurrentes en un sistema:
• Facilita la programación de aplicaciones al permitir que éstas se estructuren como un conjunto
de procesos que cooperan entre sí para alcanzar un objetivo común.
• Acelera los cálculos. Si se quiere que una tarea se ejecute con mayor rapidez, lo que se
puede hacer es dividirla en procesos, cada uno de los cuales se ejecuta en paralelo con los
demás.
• Posibilita el uso interactivo a múltiples usuarios que trabajan de forma simultánea.
• Permite un mejor aprovechamiento de los recursos, en especial de la CPU, ya que pueden
aprovechar las fases de entrada-salida de unos procesos para realizar las fases de
procesamiento de otros.
Así como existen las razones que motivan la ejecución de procesos concurrentes, también existen
sus contras:
• Inanición e interrupción de procesos
• Ocurrencia de bloqueos
• Que dos o mas procesos requieran el mismo recurso (No apropiativo)

Tipos de procesos concurrentes.

Los procesos que ejecutan de forma concurrente en un sistema se pueden clasificar como:
Proceso independiente: Es aquel que ejecuta sin requerir la ayuda o cooperación de otros
procesos. Un claro ejemplo de procesos independientes son los diferentes shells que se ejecutan de
forma simultánea en un sistema.
Procesos son cooperantes: Son aquellos que están diseñados para trabajar conjuntamente en
alguna actividad, para lo que deben ser capaces de comunicarse e interactuar entre ellos.
En ambos tipos de procesos (independientes y cooperantes), puede producirse una serie de
interacciones entre ellos y pueden ser de dos tipos:
• Interacciones motivadas porque los procesos comparten o compiten por el acceso a recursos
físicos o lógicos. Por ejemplo, dos procesos independientes compiten por el acceso a disco o
para modificar una base de datos.
• Interacción motivada porque los procesos se comunican y sincronizan entre sí para alcanzar
un objetivo común, Por ejemplo, un compilador que tiene varios procesos que trabajan
conjuntamente para obtener un solo archivo de salida.

Elementos a gestionar y diseñar a causa de la concurrencia.

Se pueden enumerar los siguientes:
1. El sistema operativo debe ser capaz de seguir la pista de los distintos procesos activos. Esto lo
hace por medio de PBC’s (Bloque de Control de Procesos)
2. El sistema operativo debe asignar y quitar los distintos recursos a cada proceso activo. Entre estos
recursos se incluyen:
• Tiempo de procesador: Es función de la planificación.
• Memoria: La mayoría de los sistemas operativos emplean esquemas de memoria virtual.
• 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 relativa a la que se realiza
la ejecución con respecto a otros procesos concurrentes.
Cuando dos o más procesos llegan al mismo tiempo a ejecutarse, se dice que se ha presentado una
concurrencia de procesos. Es importante mencionar que para que dos o más procesos sean
concurrentes, es necesario que tengan alguna relaciones entre ellos como puede ser la cooperación
para un determinado trabajo o el uso de información y recursos compartidos, por ejemplo: en un
sistema de un procesador, la multiprogramación es una condición necesaria pero no suficiente para
que exista concurrencia, ya que los procesos pueden ejecutarse de forma totalmente independiente.
Por otro lado en un sistema de varios procesos se puede presentar la concurrencia siempre y cuando
las actividades necesiten actuar entre ellos sea para utilizar información como para cualquier otra
cosa.

2.4.1 Exclusión Mutua Secciones Criticas

Regiones críticas
Es posible clasificar las interacciones de los procesos en función del nivel de conocimiento que cada
proceso tiene de la existencia de los demás:
• Los procesos no tienen conocimiento de los demás: Estos son procesos independientes que no
están pensados para operar juntos.
• Los procesos tienen un conocimiento indirecto de los otros: Los procesos no conocen
necesariamente a los otros, pero comparten el acceso a algunos objetos.
• Los procesos tienen un conocimiento directo de los otros: Los procesos son capaces de
comunicarse con los demás y están diseñados para trabajar conjuntamente en alguna actividad.

Competencia entre procesos por los recursos

Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso, es
decir, quieren acceder a un recurso al mismo tiempo. Y la ejecución de un proceso puede influir en el
comportamiento de los procesos que compiten y el sistema operativo le asignará el recurso a uno de
ellos y el otro tendrá que esperar. Por lo que el proceso que quede esperando, se retrasará, se
bloqueara y en el peor de los casos nunca se terminará con éxito.
Es en estos procesos concurrentes, donde, se plantean una serie de situaciones clásicas de
comunicación y sincronización, entre ellos el problema de la sección crítica.
El problema de la sección crítica es uno de los problemas que con mayor frecuencia aparece cuando
se ejecutan procesos concurrentes.
Para entender un poco mejor el concepto se presenta el siguiente ejemplo: Se tiene un Sistema
Operativo que debe asignar un identificador de proceso (PID) a dos procesos en un sistema
multiprocesador. Cuando el SO realiza esta acción en dos procesadores de forma simultánea sin
ningún tipo de control, se pueden producir errores, ya que se puede asignar el mismo PID a dos
procesos distintos. Este problema se debe a que constituyen una sección crítica que debe ejecutarse
en forma atómica, es decir, de forma completa e indivisible y ningún otro proceso podrá ejecutar dicho
código mientras el primero no haya acabado su sección.
Solución a la sección crítica
Para resolver el problema de la sección crítica es necesario utilizar algún mecanismo de
sincronización que permita a los procesos cooperar entre ellos sin problemas. Este mecanismo debe
proteger el código de la sección crítica y su funcionamiento básico es el siguiente:
• Cada proceso debe solicitar permiso para entrar en la sección crítica, mediante algún
fragmento de código que se denomina de forma genérica entrada en la sección crítica.
• Cuando un proceso sale de la sección critica debe indicarlo mediante otro fragmento de
código que se denomina salida de la sección crítica. Este fragmento permitirá que otros
procesos entren a ejecutar el código de la sección crítica.
Cualquier solución que se utilice para resolver este problema debe cumplir los tres requisitos
siguientes:
• Exclusión mutua: Si un proceso está ejecutando código de la sección crítica, ningún otro
proceso lo podrá hacer.
• Progreso: Si ningún proceso está ejecutando dentro de la sección crítica, la decisión de qué
proceso entra en la sección se hará sobre los procesos que desean entrar.
• Espera acotada: Debe haber un límite en el número de veces que se permite que los demás
procesos entren a ejecutar código de la sección crítica después de que un proceso haya
efectuado una solicitud de entrada y antes de que se conceda la suya.

Exclusión mutua
La exclusión mutua la podríamos definir como una operación de control que permite la coordinación
de procesos concurrentes, y que tiene la capacidad de prohibir a los demás procesos realizar una
acción cuando un proceso haya obtenido el permiso.
El control de la competencia involucra al sistema operativo inevitablemente, porque es el sistema
operativo el que asigna los recursos. Además, los procesos deben ser capaces por sí mismos de
expresar de algún modo los requisitos de exclusión mutua, como puede ser bloqueando los recursos
antes de usarlos.
Hacer que se cumpla la exclusión mutua crea dos problemas de control adicionales.
• Interbloqueo. Si se tienen dos procesos P1 y P2 y dos recursos críticos, R1 y R2. Supóngase
que cada proceso necesita acceder a ambos recursos para llevar a cabo una parte de su
función. En tal caso, es posible que se presente la siguiente situación: el sistema operativo
asigna R1 a P2 y R2 a P1. Cada proceso está esperando a uno de los dos recursos. Ninguno
liberará el recurso que ya posee hasta que adquiera el otro y ejecute su sección crítica.
Ambos procesos están ínterbloqueados.
• Inanición. Supóngase que tres procesos, P1, P2 y P3, necesitan acceder periódicamente al
recurso R. Considérese la situación en la que P1 está en posesión del recurso y tanto P2
como P3 están parados, esperando al recurso. Cuando P1 abandona su sección crítica, tanto
P2 como P3 deben poder acceder a R. Supóngase que se le concede el acceso a P3 y que,
antes de que termine su sección crítica, P1 solicita acceso de nuevo. Si se le concede el
acceso a P1 después de que P3 termine y si P1 y P3 se conceden el acceso repetidamente el
uno al otro, se puede negar definidamente a P2 el acceso al recurso.

Requisitos para la exclusión mutua.

El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones críticas y
hacer cumplir la exclusión mutua. Esto es fundamental para cualquier esquema de proceso
concurrente. Cualquier servicio o capacidad que dé soporte para la exclusión mutua debe cumplir los
requisitos siguientes:
1. Debe cumplirse la exclusión mutua: Solo un proceso, de entre todos los que poseen secciones
críticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en
un instante dado.
2. Un proceso que se interrumpe en una sección no crítica debe hacerlo sin estorbar a los otros
procesos.
 3. Un proceso no debe poder solicitar acceso a una sección crítica para después ser demorado
indefinidamente; no puede permitirse el interbloqueo o la inanición.
4. Cuando ningún proceso está en su sección crítica, cualquier proceso que solicite entrar en la
suya debe poder hacerlo sin dilación.
5. No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su número.
6. Un proceso permanece en su sección crítica solo por un tiempo finito.

Soluciones a la exclusión mutua

Hay varias formas de satisfacer los requisitos de exclusión mutua:

Soluciones por Software. Una manera es dejar la responsabilidad a los procesos que deseen
ejecutar concurrentemente, de esta manera los procesos deben coordinarse unos con otros para
cumplir la exclusión mutua sin ayuda alguna, aunque estas soluciones son propensas a errores y a
una fuerte carga de proceso (Algunos ejemplos de estas son: Algoritmo de Dekker y Algoritmo de
Peterson).
Soluciones por Hardware. Propone el uso de instrucciones de la máquina a tal efecto, estas tienen
la ventaja de reducir la sobrecarga.
El tercer método consiste en dar algún tipo de soporte en el sistema operativo, entre estos métodos
se encuentran los semáforos, monitores, paso de mensajes, etc.

2.4.2 Sincronización Procesos en SO

Según la investigación de Tanenbaum y Woodhull (1997) la sincronización es la transmisión y

recepción de señales que tiene por objeto llevar a cabo el trabajo de un grupo de procesos
cooperativos. Es la coordinación y cooperación de un conjunto de procesos para asegurar la
comparación de recursos de cómputo. La sincronización entre procesos es necesaria para prevenir
y/o corregir errores de sincronización debidos al acceso concurrente a recursos compartidos. La
sincronización permite intercambiar señales de tiempo (arranque/parada entre procesos cooperantes
para garantizar las relaciones específicas de precedencia impuestas por el problema que se resuelve.
Sin una sincronización adecuada entre procesos, la actualización de variables compartidas puede
inducir a errores de tiempo relacionados con la concurrencia que son con frecuencia difíciles de
depurar.

Para que los procesos puedan sincronizarse es necesario disponer de servicios que permitan
bloquear o suspender bajo determinadas circunstancias la ejecución de un proceso. Los principales
mecanismos de sincronización que ofrecen los sistemas operativos son:
• Señales.
• Tuberías.
• Semáforos.
• Mutex y variables condicionales.
• Paso de mensajes.
• Tuberías.
Una tubería es un mecanismo de comunicación y sincronización. Conceptualmente, cada proceso ve
la tubería como un conducto con dos extremos, uno de los cuales se utiliza para escribir o insertar
datos y el otro para extraer o leer datos de la tubería.

2.4.2.1. Mecanismo de Semáforos

Un mecanismo semáforo consta básicamente de dos operaciones primitivas señal (Signal) y espera
(Wait) (Originalmente definidas como P y V por Disjkstra), que operan sobre un tipo especial de
variable semáforo, “s”. La variable semáforo puede tomar valores enteros y, excepto posiblemente en
su inicialización, solo puede ser accedida y manipulada por medio de las operaciones SIGNAL y
WAIT. Ambas primitivas llevan un argumento cada una, la variable semáforo, y pueden definirse del
modo siguiente..:
SIGNAL (s) ..:
Incrementa el valor de su argumento semáforo, s , en una operación indivisible.
WAIT (s) ..:
Decrementa el valor de su argumento semáforo, s , en tanto el resultado no sea negativo. La
conclusión de la operación WAIT, una vez tomada la decisión de decrementar su argumento
semáforo, debe ser individual.
Ejemplo..:
Wait(s): While not (s > 0) do {Seguir Probando};
S := s - 1;
Signal(s) s := s + 1;
Un semáforo cuya variable solo tiene permitido tomar los valores 0 (ocupado) y 1 (libre) se denomina
Semáforo Binario. Un Semáforo General puede tomar cualquier valor entero. La lógica de las
operaciones WAIT y SIGNAL aplica tanto para Semáforos Binarios como Semáforos Generales.

Propiedades
Los semáforos son un mecanismo relativamente sencillo pero poderoso de asegurar la exclusión
mutua entre procesos concurrentes para acceder a un recurso compartido. En vez de que lo usuarios
inventen sus propios protocolos de sincronización (tarea difícil y traicionera) los semáforos son una
herramienta proporcionada por el diseñador de sistemas. Los usuarios solo necesitan contribuir a
controlar el acceso a los recursos compartidos obedeciendo un protocolo estándar y sencillo.
Los semáforos pueden estar disponibles en un lenguaje de programación, como construcción del
lenguaje, o como servicio del sistema operativo invocado mediante llamadas al sistema. Cuando son
proporcionadas por el sistema operativo, las variables semáforos no son declaradas ni manipuladas
en el lenguaje, sino que se manipulan a través de llamadas al sistemas tales como ..:
CREAR_SEMAFORO, ASOCIAR_A_SEMAFORO, ESPERAR, SEÑAL, CERRAR_SEMAFORO.

Disciplina de Servicio de los Semáforos

La definición de semáforo con espera activa no impone la aplicación de ninguna ordenación a los
procesos que esperan, existe, por tanto, una posibilidad de que un proceso pueda quedar bloqueado
debido a la competencia con otros. Esta situación, en la cual algunos procesos progresan hacia su
terminación pero uno o más procesos permanecen bloqueados fuera del recurso, se denomina
Aplazamiento Indefinido. Este fenómeno también es conocido como Bloqueo Activo, y los procesos
afectados se dicen que son Postergados. Para evitar bloqueos activos algunas implementaciones de
semáforos obligan a aplicar una disciplina de servicio entre los procesos en espera.
La elección de una disciplina de servicio es muy importante ya que una disciplina sesgada puede
posibilitar que un grupo de procesos conspire contra otros y usurpe permanentemente el recurso.
La postergación de procesos puede evitarse añadiendo el siguiente requisito a la implementación de
semáforo. “Una petición para entrar a la sección critica debe ser concedida en tiempo finito”. Dada la
suposición de que cada proceso tarda un tiempo finito en ejecutar la sección critica, este requisito
puede satisfacerse utilizando la disciplina FIFO (First Input First Output - “Primero en entrar... Primero
en Salir”) para elegir entre los procesos en espera. Este método garantiza la entrada a la sección
crítica en tiempo finito, como también es conocido como Implementación Estricta de Semáforos.

Implementación de Semáforos con Colas

La implementación de los semáforos con espera activa tienen dos importantes desventajas .: el
potencial aplazamiento indefinido y la baja eficiencia debido al consumo de ciclos de procesador por
parte de procesos bloqueados. Aunque un proceso bloqueado no experimenta ningún proceso real,
no obstante continua consumiendo recursos del sistema a causa de la espera activa. Tanto el
bloqueo activo como la ineficaz espera activa pueden verse aliviados por la implementación de
semáforos con cola.
Un proceso suspendido no consume ciclos de procesador, de modo que este método es
potencialmente más eficiente que el de la espera activa.

2.4.2.2. Mecanismo de Monitores

Es un proceso que se encarga de verificar el funcionamiento de algún recurso garantizando la
exclusión mutua (mutex).

• En un monitor los procesos se bloquean y desbloquean.

• Pueden existir diversas implementaciones no estandarizadas de un monitor.
• En Java los monitores están implementados de manera nativa con el modificador de los
métodos syncronized.
• El monitor es el mecanismo que nos permite controlar el acceso a una región crítica, en este
caso un método. También se puede utilizar semáforos como objetos mutex disponibles en el
paquete java.util.concurrent.

2.4.3 Interbloqueo DeadLock

El interbloqueo puede definirse formalmente como sigue: Un conjunto de procesos está en
interbloqueo si cada proceso del conjunto está esperando un evento que sólo otro proceso del
conjunto puede causar. Puesto que todos los procesos están esperando, ninguno de ellos puede
causar ninguno de los eventos que podrían despertar a cualquiera de los demás miembros del
conjunto, y todos los procesos continúan esperando indefinidamente.

2.4.3.1 Prevencion Interbloqueo DeadLock

La estrategia de prevención del interbloqueo consiste, a grandes rasgos, en diseñar un sistema de
manera que esté excluida, a priori, la posibilidad de interbloqueo. Los métodos para prevenir el
interbloqueo son de dos tipos. Los métodos indirectos consisten en impedir la aparición de alguna de
las tres condiciones necesarias. Los métodos directos consisten en evitar la aparición del círculo
vicioso de espera.

Los bloqueos mutuos pueden ser evitados si se sabe cierta información sobre los procesos antes de
la asignación de recursos. Para cada petición de recursos, el sistema controla si satisfaciendo el
pedido entra en un estado inseguro, donde puede producirse un bloqueo mutuo. De esta forma, el
sistema satisface los pedidos de recursos solamente si se asegura que quedará en un estado seguro.
Para que el sistema sea capaz de decidir si el siguiente estado será seguro o inseguro, debe saber
por adelantado y en cualquier momento el número y tipo de todos los recursos en existencia,
disponibles y requeridos.
2.4.3.2 Detección Interbloqueo DeadLock
Según William Stallings (1999) las estrategias de prevención del interbloqueo son muy
conservadoras; solucionan el problema del interbloqueo limitando el acceso a los recursos e
imponiendo restricciones a los procesos. En el lado opuesto, las estrategias de detección del
interbloqueo no limitan el acceso a los recursos ni restringen las acciones de los procesos. Con
detección del interbloqueo, se concederán los recursos que los procesos necesiten siempre que sea
posible. Periódicamente, el sistema operativo ejecuta un algoritmo que permite detectar la condición
de círculo vicioso de espera. Puede emplearse cualquier algoritmo de detección de ciclos en grafos
dirigidos.

El control del interbloqueo puede llevarse a cabo tan frecuentemente como las solicitudes de recursos
o con una frecuencia menor, dependiendo de la probabilidad de que se produzca el interbloqueo. La
comprobación en cada solicitud de recurso tiene dos ventajas: Conduce a una pronta detección y el
algoritmo es relativamente simple, puesto que está basado en cambios increméntales del estado del
sistema. Por otro lado, tal frecuencia de comprobaciones consume un tiempo de procesador
considerable. Una vez detectado el interbloqueo, hace falta alguna estrategia de recuperación.
2.4.3.3 Recuperación Interbloqueo DeadLock
Según William Stallings (1999) Las técnicas siguientes son posibles enfoques, enumeradas en orden
creciente de sofisticación:
1. Abandonar todos los procesos bloqueados. Esta es, se crea o no, una de las soluciones más
comunes, si no la más común, de las adoptadas en un sistema operativo.
2. Retroceder cada proceso interbloqueado hasta algún punto de control definido previamente y
volver a ejecutar todos los procesos. Es necesario que haya disponibles unos mecanismos de
retroceso y reinicio en el sistema. El riesgo de esta solución radica en que puede repetirse el
interbloqueo original. Sin embargo, el no determinismo del procesamiento concurrente asegura, en
general, que esto no va a pasar.
3. Abandonar sucesivamente los procesos bloqueados hasta que deje de haber interbloqueo. El
orden en el que se seleccionan los procesos a abandonar seguirá un criterio de mínimo coste.
Después de abandonar cada proceso, se debe ejecutar de nuevo el algoritmo de detección para ver
si todavía existe interbloqueo.
4. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo. Como en el punto 3,
se debe emplear una selección basada en coste y hay que ejecutar de nuevo el algoritmo de
detección después de cada apropiación. Un proceso que pierde un recurso por apropiación debe
retroceder hasta un momento anterior a la adquisición de ese recurso.

2.5 NIVELES OBJETIVOS CRITERIOS PLANIFICACIÓN

Se consideran tres niveles importantes de planificación, los que se detallan a continuación:

• Planificación de alto nivel: Se encarga de llevar procesos de disco a memoria y viceversa.
Seleccionando los trabajos que deben admitirse en el sistema.
• Planificación de nivel intermedio: En algunos casos, en especial cuando el sistema está
sobrecargado, el planificador de nivel medio encuentra ventajoso retirar trabajos activos de la
memoria para reducir el grado de multiprogramación, y por lo tanto, permitir que los trabajos se
completen más aprisa.
• Planificación de bajo nivel: Se encarga de pasar de un proceso a otro en memoria principal.
Determinando a cuál proceso listo se le asignará el CPU cuando éste se encuentra disponible. O
Determina a qué proceso listo se le asigna la cpu cuando esta queda disponible y asigna la cpu al
mismo, es decir que “despacha” la cpu al proceso.

Los objetivos de la planificación del procesador:

• Ser justa.
• Maximizar la capacidad de ejecución.
• Maximizar el número de usuarios interactivos.
• Ser predecible.
• Equilibrar el uso de recursos.
• Equilibrar respuesta y utilización.
• Evitar la postergación indefinida.
• Asegurar la prioridad.
• Dar preferencia a los procesos que mantienen recursos claves.
• Dar mejor tratamiento a los procesos que muestren un “comportamiento deseable”.
• Degradarse suavemente con cargas pesadas.

Criterios de la planeación del procesador

• Equidad
• Eficacia
• Tiempo de respuesta
• Tiempo de regreso
• Rendimiento
2.6 TÉCNICAS ADMINISTRACIÓN DEL PLANIFICADOR

Se denomina planificador al software del sistema operativo encargado de asignar los recursos de un
sistema entre los procesos que los solicitan. Siempre que haya tomar una decisión, el planificador
debe decidir cuál de los procesos que compiten por la posesión de un determinado recursos lo
recibirá.

Los algoritmos (técnicas) tienen distintas propiedades según los criterios en los que se basen para su
construcción, lo cual se refleja en qué tipo de procesos se puede ver favorecido frente a otro en la
disputa del procesador. Antes de realizar la elección de un algoritmo se debe considerar las
propiedades de estos frente al criterio de diseño elegido.

2.6.1FIFO
Se concluye lo siguiente:
FIFO: First In First Out

Mecanismo de scheduling en el cual los procesos se ordenan en una fila, en la cual se ejecutan cada
uno de los procesos hasta su finalizacion secuencialmente. Es tremendamente ineficiente.

Cuando se tiene que elegir a qué proceso asignar la CPU se escoge al que llevara más tiempo listo.
El proceso se mantiene en la CPU hasta que se bloquea voluntariamente. Para implementar el
algoritmo sólo se necesita mantener una cola con los procesos listos ordenada por tiempo de llegada.
Cuando un proceso pasa de bloqueado a listo se sitúa el último de la cola.

2.6.2 SJF
Vemos que al igual que en el algoritmo FIFO las ráfagas se ejecutan sin interrupción, por tanto, sólo
es útil para entornos batch. Su característica es que cuando se activa el planificador, éste elige la
ráfaga de menor duración. Es decir, introduce una noción de prioridad entre ráfagas.
Hay que recordar que en los entornos batch se pueden hacer estimaciones del tiempo de ejecución
de los procesos. La ventaja que presenta este algoritmo sobre el algoritmo FIFO es que minimiza el
tiempo de finalización promedio.

2.6.3 RR
Vemos que cada proceso tiene asignado un intervalo de tiempo de ejecución, llamado cuantum o
cuánto. Si el proceso agota su cuantum de tiempo, se elige a otro proceso para ocupar la CPU. Si el
proceso se bloquea o termina antes de agotar su cuantum también se alterna el uso de la CPU.
El round es muy fácil de implementar. Todo lo que necesita el planificador es mantener una lista de
los procesos listos.

2.6.4 QuevesMultilevel
Según Tanenbaum y Woodhull (1997) es un algoritmo de planificación multinivel particiona la cola de
listos en colas separadas. Se asignan en forma permanente los trabajos a una cola, generalmente,
basándose en alguna propiedad del mismo (requerimientos de memoria, tipo de trabajo), teniendo
cada cola su propio algoritmo. Por ejemplo, la cola interactiva podría planificarse usando RR y la
batch FIFO.

Ningún trabajo en una cola de baja prioridad puede ejecutarse si las colas con mayor prioridad no
están vacías. Si algún trabajo entra en una cola de mayor prioridad, el trabajo de otras colas es
interrumpido.

2.6.5 MultiLevel Feedback Queves

En colas multinivel realimentadas los trabajos pueden moverse dentro de distintas colas. La idea es
separar procesos con distintos tipos de interrupciones de la CPU. Si un trabajo consume mucho
tiempo de CPU, será movido a una cola con menor prioridad.
En forma similar, si un proceso espera demasiado tiempo en una cola de baja prioridad, lo
moveremos a una cola de mayor prioridad.
En general un planificador de este tipo está definido por los siguientes parámetros:
1. El número de colas.
2. El tipo de algoritmo de planificación de cada cola.
3. Un método de determinación de cuando mover un trabajo a una cola de mayor prioridad.
4. Un método de determinación de cuando mover un trabajo a una cola de menor prioridad.
5. Un método de determinación de a qué cola se enviará un trabajo cuando necesita servicio.
 INSTITUTO TECNOLÓGICO
ZACATEPEC

ING. SISTEMAS COMPUTACIONALES

SISTEMAS OPERATIVOS

JESÚS ÁNGEL PEÑA RAMÍREZ

GRUPO: B

TANIA VÁZQUEZ DEGANTE

NO. LISTA: 11