Partes de una PC:

-CPU (cerebro que piensa)

-Unidad de Control (entiende qué hacer, cómo y cuándo)

-UAL (hacer cálculos y tomar decisiones)

-Registros (cajas donde pongo datos)

-Unidades de almacenamiento (RAM)

-Dispositivos E/S

-Buses (canales de comunicación), de control, de dirección y de datos.

Funcionamiento de la PC:

El CPU se conecta con la memoria y recibe un input de algún lado y me devuelve un resultado.

El CPU se conecta con el bus de control, direcciones y datos.

El bus que lleva datos se conecta con los dispositivos E/S, para entrar y llevar información. Los
datos son enviados a la CPU para ser procesados, y los resultados se almacenan o se toman
desde la memoria.

El bus de control se le da la indicación de cuál es la operación, qué quiero hacer con los datos
que están almacenados en la memoria y fueron provistos por la entrada.

Registros

Están adentro del CPU. Almacenan información temporal para hacer los cálculos en el CPU. Si
el CPU no obtiene la información en los registros, la busca en la memoria.

Tipos de registros:

De uso general: Acumulador, Contador (cuenta pasos u operaciones o instrucciones), Base

(donde comencé) y Datos.

Uso específico:

-Stack Pointer: apunta a la parte superior de la pila (stack) actual en la memoria. La pila
contiene un conjunto de valores por cada procedimiento al que se ha entrado, pero del que
todavía no se ha salido. El conjunto de valores en la pila por procedimiento contiene los
parámetros de entrada, las variables locales y las variables temporales que no se mantienen en
los registros.

-Instruction Pointer: apunta a una instrucción actual.

-Program Counter: tiene la dirección de la próxima instrucción.

-Program Status Word: Da información sobre cuál es el modo actual de ejecución (usuario o
privilegiado).

De segmento (no es importante).

De control (no es importante).

Interrupciones

Interrumpen el flujo de ejecución (secuencia de instrucciones). Implican un cambio en el modo

de ejecución. Hay distintos niveles de urgencia y pueden actuar con distintos componentes
(software, hardware, CPU, reloj).

-Internas: Están adentro del CPU, y el CPU solo puede procesar software. Es interna <=> es de
software.

-Externas: Están afuera del CPU. Es externa <=> es de hardware.

-Excepciones: Son internas. Comportamiento no esperado. Frena el flujo del programa.

-Traps: Son Excepciones. Funciones preprogramadas dentro de una biblioteca. Requieren

permisos de administrador, ya que las maneja el Syscall, y el Syscall justamente lo que hace es
pedir permisos administrativos.

-Enmascarable: Lo puedo ignorar. Puede ser interna o externa.

-No enmascarable: No lo puedo ignorar. Puede ser interna o externa.

-Sincrónica: Está sincronizada con el ciclo que el reloj trae. Suelen ser internas.

-Asincrónica: Llegan cuando quieren. Suelen ser de externas.

TODAS LAS INTERRUPCIONES SE TRATAN POR SOFTWARE.

Procesamiento de interrupciones:

Si es por hardware, el controlador (driver) le traduce al Sistema Operativo lo que pasa. Genera
una interrupción. El procesador toma esa interrupción, pero primero completa la ejecución de
la instrucción en curso. Identifica quien envía la interrupción, coloca el PC y el PSW en la pila
del sistema, y después carga el nuevo PC.

La rutina guarda el resto de la información del estado de la CPU, se procesa la interrupción, se

restaura la información del estado de la CPU y se restaura el anterior PC y PSW.

Todo esto lo maneja el interrupt handler (controlador de interrupciones de hardware). Para

manejar las interrupciones y ver las prioridades, utiliza un sistema llamado IRQ.

Cómo se acomodan las interrupciones:

Excepciones: manejados por el manejador de excepciones.

Tabla de IRQ: manejados por el interrupt handler.

Traps: Gestor de llamadas al sistema.

Ciclo de instrucción con interrupciones:

El procesamiento de la interrupción es una instrucción.

Ciclo de instrucción atómico: Interrupciones inhabilitadas. No puede ser interrumpido.

Sistemas Operativos - Kernel

NO existe una definición formal.

La base de un sistema operativo es el Kernel. Entre el núcleo y el hardware están los drivers.
Sobre el kernel están las system calls (el que trata las traps). Sobre eso están las bibliotecas
donde se guardan las traps. Arriba de eso están las aplicaciones.

Mientras más “arriba” estoy, más trato con software, y mientras más “abajo”, más trato con
hardware. El que está en el medio, es el Kernel.

Mientras más me acerco al núcleo, más privilegios necesito.

Las interrupciones de hardware SOLO se pueden tratar si soy administrador, ya que el único
que se comunica con el hardware es el kernel a través de los drivers.

Llamadas al sistema:

-System calls: Solicitud de un programa en modo usuario para realizar una operación que
requiere permisos de administrador.

-Wrappers: Función que ejecuta cierta System Call para un lenguaje particular.

Tipos de núcleos

Monolítico: El 100% del núcleo requiere permisos de administrador. El núcleo se encarga de

todo. Suele ser chico. Casi no presenta llamadas al sistema. Si presenta fallas se destruye todo.

Microkernel: el núcleo solo maneja interrupciones, procesos, planificación e IPC. El modo

usuario posee todas las demás funciones. Son robustos, no pinchan. La desventaja es el
retardo.
Kernel con capas: La capa más alta es la de usuario y la más baja es la primitiva. Las capas
siempre prestan servicios a la capa inmediatamente posterior o inferior.

Seguridad

Cuanto más cerca estamos del hardware, mayor es el nivel de vulnerabilidad.

Procesos

Es un programa (o un conjunto de programas) que está en ejecución y tienen relación entre

ellos. Secuencia de instrucciones que se está ejecutando. Tiene un estado actual y un conjunto
de recursos asociados.

Programa: Conjunto de algoritmos escritos en una computadora. Proceso que no está en

ejecución.

Tarea: Lista de procesos.

¿Cómo administra un proceso el Sistema Operativo?

-A través del PCB: conjunto de registros creados cuando un nuevo proceso ingresa al sistema.
Desaparece cuando el proceso finaliza. Es visible para el sistema operativo.

Registros del PBC:

+ID del proceso.

+Información del estado del procesador: valores de los diferentes registros (PC, PWS , etc) que
tiene el procesador en un instante, conocido como CONTEXTO.

+Control del proceso: estructuras asociadas al proceso (estado del CPU, etc) y recursos
asignados. Por ejemplo, la pantalla o el mouse.

-A través de la imagen del proceso: estructura que contiene al PBC y referencia todos los
recursos que el proceso utiliza (usuario y kernel). Solo es visible para el sistema operativo
cuando su referencia está en el PBC.

Registros de la imagen:

+PBC

+Pila de usuario: parámetros y variables de usuario.

+Espacio privado de direcciones de usuario: todo aquello guardado en la memoria.

+Pila del núcleo: para hacer acciones administrativas (llamada al sistema, cambio de modo,
etc)

+Espacio de direcciones compartido (Heap): datos para uso del programa o para compartir con
otros programas.

Tabla de procesos

Los procesos se controlan a través de una tabla (administrador de tareas). Allí se encuentran
todas las PBC de los procesos.

Estado de un proceso: comportamiento que puede tomar un proceso.

Modelos de estados

Modelo 2 estados:

No puede haber más de un proceso en ejecución a la vez.

Dispatcher: Maneja la Planificación a Corto Plazo. Es responsable de la activación de procesos.

Planificación a Corto Plazo: Algoritmo utilizado para determinar el orden en el que se realizará
la activación de cada proceso.

Activación: asignar el uso del procesador a un determinado proceso.

Temporización: finalización del uso del CPU para un proceso.

Finalización: condición en la que un estado de proceso cambia a saliente.

Modelo de 5 estados:
Las interrupciones le avisan al sistema operativo cuando ocurre un evento que implica un
bloqueo de proceso.

Este modelo se queda corto, porque no me deja ver la imagen de los procesos.

Diagrama de 6 estados:

Si el proceso está bloqueado por mucho tiempo, pasa al estado de suspendido, y la imagen es
enviada a la Memoria Virtual. Este proceso es conocido como SWAP.

Memoria Principal: RAM

Memoria Secundaria: Disco/Memoria Virtual (MV)

Diagrama de 7 estados (EL MÁS IMPORTANTE):

Operaciones en procesos

Creación: Asigna un ID, reserva espacio para la imagen, inicia la PCB, establece enlaces y ajusta
las estructuras de datos y de control del sistema operativo.

Process Switch: salida de un proceso que está utilizando el procesador para provocar la
entrada de otro proceso que estaba esperando en la cola de listos y el dispatcher decide que
es el próximo a ejecutar.

Interrumpe el proceso actual, actualiza los estados y contexto y activa el proceso entrante.

Cambia de un proceso en ejecución a otro proceso en ejecución.

Requiere 2 Mode Switch y 1 Context Switch.

Context Switch: guarda el valor de los registros del proceso que deja de ejecutarse en la
memoria virtual y deja la referencia a esos valores en la memoria RAM. Borra todo y deja los
registros libres para que se llenen con información de otro proceso.

Cambia de ejecución de proceso a ejecución de núcleo.

Requiere AL MENOS un Mode Switch (cambio de modo).

Process Switch => Context Switch.

Definiciones importantes:

Multiprocesamiento: existencia física de más de un CPU.

Multiprogramación: técnica en la que los procesos pueden alojarse en la memoria RAM para
ser ejecutados a la par por un CPU.

Grado de multiprogramación: cantidad máxima de procesos que puedo tener en memoria

RAM.

Multitarea: noción de la ejecución simultánea de procesos en un único CPU.

PLANIFICACIÓN DE PROCESOS

Overhead: Acciones administrativas realizadas por el Sistema Operativo para gestionar

procesos. No ejecuta instrucciones de los procesos.

El objetivo es minimizar el overhead.

Menor overhead => mayor rendimiento.

Criterios de Planificación a Corto Plazo:

Orientados al Usuario:

▪ Tiempo de Retorno (Turnaround Time): Es el tiempo transcurrido desde que se lanza un

proceso hasta que finaliza (incluyendo tiempos de ejecución y espera).

▪ Tiempo de Respuesta (Response Time): Para un proceso inactivo, es el tiempo que transcurre
desde que se lanza una petición hasta que comienza a recibir la respuesta.

▪ Previsibilidad: El tiempo y trabajo de un proceso debería tomar siempre el mismo tiempo en

ser finalizado. Una gran variación en el tiempo de respuesta o en el tiempo de retorno es malo
desde el punto de vista del usuario. (Afectado por la sobrecarga del sistema)

▪ Fecha tope: El sistema operativo tiene que hacer las cosas en el tiempo que le dije que las
tiene que hacer, en el momento exacto. Ejemplo: BackUp a la noche.

Orientados al Sistema:

▪ Rendimiento: Se busca utilizar el procesador para completar la mayor cantidad de procesos

por unidad de tiempo (Ej.: 20 procesos en 1 min)

▪ Utilización del Procesador: Es el porcentaje de tiempo que el procesador está ocupado.

▪ Equidad: Se espera que el sistema operativo planifique los procesos en forma justa sin
provocar inanición.

▪ Imposición de Prioridades: Si se asignan prioridades a los procesos, la política del planificador

debería favorecer a los procesos con prioridades más altas.

▪ Equilibrado de Recursos: Ocupar los recursos lo máximo posible, favoreciendo su uso por
procesos que los requieran poco cuando tengan mayor ocupación (Implica planificación de
mediano y largo plazo también)

Todos los criterios orientados al usuario tienen que tender a minimizarse. Los orientados al
sistema tienen que tender a maximizarse.

Inanición: posponer en forma indeterminada la concesión de un recurso a un proceso que lo

necesita.
▪ Planificador a Corto Plazo (Dispatcher): Toma la decisión sobre cuál será el siguiente proceso
a ejecutar, como también cuál se debe expulsar. Es parte de los cambios de estado. Debe
tender a un bajo overhead.

▪ Planificador a Mediano Plazo: Trabaja con la memoria. Decide qué imágenes de procesos
traerá o quitará de la memoria principal. Utiliza el intercambio (Swapping) para ejecutar su rol.
Tendrá en cuenta cuál es la carga del sistema operativo basado en el Planificador de Largo
Plazo. Modifica el grado de multiprogramación.

▪ Planificador de Largo Plazo: Decide qué procesos serán Admitidos en el sistema. Controla el
Grado de Multiprogramación del sistema. Se ejecuta cuando un nuevo proceso es creado.
Decide cuándo se puede cargar un nuevo proceso y qué trabajo será aceptado y convertido en
proceso. Busca balancear el uso del CPU y los dispositivos de entrada y salida.

CPU bound: Mucho uso del CPU

IO bound: Mucho uso de dispositivos de entrada y salida.

Políticas de Planificación a Corto Plazo

Son algoritmos previamente definidos.

1. FCFS/FIFO: Sin desalojo. El primero que entra es el primero que se va. Poca equidad, poco
overhead, poca inanición.

2. ROUND ROBIN/RR: Con desalojo. Cuando ocurre una interrupción, el proceso en ejecución
es colocado en la cola de listos y el siguiente proceso es seleccionado. Alta equidad, el
overhead depende del quantum y no genera inanición.

3. VIRTUAL ROUND ROBIN/VRR: Planifica similar a Round Robin, pero la cola de bloqueados
tiene prioridad sobre la cola de listos.

4. SJF sin desalojo/SPN: Proceso con tiempo esperado más corto es seleccionado. Equidad y
overhead medio. Genera inanición.

5. SJF con desalojo/SRT: Elige proceso que le queda menos tiempo esperado de ejecución.
Equidad media-alta, overhead medio. Genera inanición.

6. HRRN: Adaptación del SPN. Se prioriza a los procesos con mayor tasa de respuesta
(Response Ratio): R.R. = (S + W) / S. Sin desalojo. Equidad alta, overhead medio. No genera
inanición.

7. FEEDBACK: Combina tres RR y un FIFO. Puede tener otros algoritmos. Overhead medio.

8. PRIORITIES (CD/SD): Con cada proceso se asocia una prioridad (número entero), y la CPU se
asigna al proceso con prioridad más alta. Poca equidad. Genera inanición. Si es con desalojo, el
overhead es medio. Caso contrario el overhead es bajo.

HILOS

Los procesos pasan a tener hilos.

Un hilo es la traza o ejecución de acciones esperadas de un proceso, basadas en la

programación del mismo. Es una unidad de planificación que utiliza la CPU y comprende: un ID
del hilo, un set de registros y una pila “propios”.

Si un proceso tiene más de un hilo, puede ejecutar múltiples tareas al mismo tiempo.

Un proceso comparte con sus hilos su sección de código, su sección de datos, y los recursos
asignados al proceso por el SO, es decir, comparte su TAREA. Los registros (contexto) y las pilas
son individuales a cada hilo.

La tarea se comparte entre hijos y padre.

Padre: generador de un hilo. Le da a sus hijos el código, el espacio de memoria, las referencias
a los archivos.

Hijo: hilo generado por el padre.

Cuando un padre se muere, los hijos se mueren porque el código desaparece.

Ventajas y beneficios de los hilos:

▪ Velocidad de respuesta (Responsiveness): Hacer una aplicación “multihilos” puede permitir al
programa continuar ejecutando cuando alguno de sus hilos se bloquea (aunque no siempre!),
o cuando hace alguna operación que toma mucho tiempo.

▪ Compartición de Recursos: Los hilos comparten la memoria y los recursos de los procesos a
los que pertenecen.

▪ Economía: Dado que los hilos en un proceso comparten los recursos, es más económico crear
y cambiar contextos de hilos.

La creación de un proceso (por ejemplo la JVM en Windows) es alrededor de 30 veces más

lenta que la creación de un hilo.

▪ Utilización de Multiprocesamiento y Arquitecturas Multi-Procesador: Determinado tipo de

hilos pueden ejecutarse en diferentes procesadores paralelamente.

Tipos de hilos

Hilos de núcleo (KLT): son visibles para el sistema operativo.

Hilos de usuario (ULT): son visibles para el programador, pero no para el sistema operativo.

▪ El núcleo soporta y administra (Planifica) los KLTs

▪ Los ULTs son implementados y planificados a través de una Biblioteca de Hilos.

▪ En general, los ULTs son creados con mayor velocidad que los KLTs (y por consecuencia, que
los procesos), porque no se requiere intervención del Kernel.

▪ Un proceso puede crear uno o más KLTs.

▪ Un KLT puede crear uno o más ULTs.

▪ Los ULTs son la creación de diferentes ramas del código de la programación.

Cuando tenemos un solo hilo conductor (sin ULTs), se trata como si fuera un solo proceso.

Modelos Multihilo

Uno a uno: Cada Hilo de usuario se mapea con un hilo de Kernel

– Hay mayor nivel de competitividad por recursos que en el modelo Muchos a Uno.

– Permite ejecutar otros hilos de Kernel cuando alguno de ellos está bloqueado.

– Crear un nuevo hilo de usuario requiere crear un nuevo hilo de kernel (más overhead!)

– Crear demasiados hilos de Kernel para el mismo proceso, puede ser ineficiente.

– Diferentes hilos de esta combinación, pueden usar diferentes procesadores, en caso de

haber más de uno.
-Es visto en todo su contexto por el sistema operativo.

-No se pueden crear infinitamente.

Muchos a uno: Muchos hilos de Usuario mapeados a un único hilo de Kernel

– La administración de los hilos es realizada por la Biblioteca de Hilos (hacen lo mismo que las
syscalls).

– Es eficiente. Se pueden crear tantos hilos como se desee.

– Todo el Proceso/KLT se va a bloquear si se hace una Llamada al Sistema bloqueante.

– Aunque se tengan múltiples procesadores, los hilos de estas combinaciones sólo utilizarán
uno.

-Para crear o modificar hilos de usuario, el sistema operativo no ejecuta ninguna tarea
administrativa.

- Una buena práctica es crear programas que tengan muchos ULTs cuando en realidad lo que
voy a usar es mucho procesador, porque puedo repartir el tiempo del procesador entre los
distintos ULTs.

-Si tengo muchas interrupciones, no es buena práctica tener muchos ULTs.

Muchos a muchos: permite muchos hilos de usuario mapeados a menos hilos de kernel

– Permite al SO crear la cantidad necesaria de hilos de Kernel

– El número de hilos de Kernel podrá ser específico a una aplicación o un tipo de máquina.
Debe existir no solo un balance desde el sistema operativo (para manejar el planificador de
largo plazo), sino también del lado del programador, que tiene que tener una idea de para qué
hardware está programando. Mientras más conocimiento, más eficiente puede ser la
programación.

Biblioteca de hilos

API (Application Programming Interface): conjunto de funciones que sirven al programador

para comunicar diferentes sistemas, o manejar funcionalidades específicas en la programación
de alguno de ellos. Por ejemplo, la Biblioteca de hilos provee funciones para comunicarse con
el Kernel.

Una Biblioteca de Hilos provee al programador una API para crear y manejar los hilos.

Dos formas de implementación:

▪ Biblioteca entera en el espacio de Usuario sin soporte para Kernel:

- Todos los datos y estructuras de la librería existen en el espacio de Usuario.

- Todas las funciones y llamadas se realizan en el espacio de Usuario

▪ Funciones a nivel de kernel soportadas por el SO:

-Todos los datos y estructuras existen en el espacio de Kernel

-El invocado de funciones puede resultar en System Calls al Kernel

La biblioteca de hilos no es única. Existe por cada lenguaje de programación, ya que los
programas son creados en distintos lenguajes.

LWP – Light Weight Process

Estructura intermedia colocada en algunos sistemas con modelo Muchos a Muchos entre los
KLT y los ULT.

–Sirve para manejar las funciones de administración y control de los ULTs.

– Un ULT se encuentra conectado con un LWP.

– Cada LWP se conecta con un KLT.

– El sistema operativo planifica los KLTs para utilizar el CPU.

– Si el KLT se bloquea, el LWP se bloquea y todos los ULT se bloquean.

– Para la Biblioteca de Hilos (ULTs), el LWP se comporta como un CPU “virtual” en el que la
aplicación puede planificar la ejecución de los ULTs.

– La Biblioteca de Hilos es responsable por la Planificación entre los ULTs.

– En general el cambio de contexto entre ULTs implica tomar el contexto del ULT que está
utilizando el LWP y reemplazarlo por el de otro ULT.

-Pueden existir: cambios de contexto para hilos y cambios de hilos.

-El LWP no genera cambio de modo, porque el cambio de modo ya ocurrió porque estoy a
nivel de kernel, o porque estoy a nivel de usuario, y no hay cambio de modo. El cambio de
modo lo tendrá que hacer eventualmente el KLT.

–Solo existe cuando hay más de un ULT.

–Procesa un ULT a la vez.

Estados de los ULT

– Creación (Spawn): Un ULT es iniciado. Se carga y se ejecuta.

– Bloqueado (Blocked): Un ULT solicita un recurso y debe esperar a que le sea asignado a su
correspondiente KLT.

– Desbloqueado/Listo (Unlock/Ready): El recurso es asignado al KLT.

– Ejecutando (Running)

– Finalizado: Se liberan los recursos ocupados por contexto y pila del hilo (en el LWP).

El estado suspendido no existe para los hilos de usuario.

Planificación de hilos

El dispatcher solo maneja KLTs, ya que estamos trabajando con el sistema operativo. Pueden
existir ULTs, pero van a estar limitado por la planificación del sistema operativo.

Prioridades:

1- Sistema Operativo

2- Procesos

3- Hilos (usuario)

Los KLT siguen la planificación del sistema operativo. Los ULT se rigen por el planificador de
hilos de usuario (biblioteca).

Ejemplo Uniprocesador – KLTs

Los KLTs compiten cuando hay un único CPU.

Ejemplo con doble núcleo – KLTs

Los hilos pueden planificarse en forma independiente por cada CPU.

A partir de ahora, múltiples hilos de kernel se pueden mandar a múltiples cores de forma
simultánea aunque correspondan al mismo proceso.

Ejemplo con Doble Núcleo – ULTs

Los ULTs sólo pueden aprovechar un único Core o CPU, independientemente de que haya más
disponibles.

Ventajas ULT: ▪ Pueden implementarse en las aplicaciones que se ejecutaban en sistemas

operativos que no son capaces de planificar hilos, o sea, que no pueden manejar KLTs. Esto lo
hace portable.

▪ No generan Overhead al SO

▪ No hay límite en la cantidad de ULTs que pueden crearse asociados al mismo LWP y su
correspondiente KLT.

Desventajas ULT: ▪ No son vistos por el SO por lo que su planificación queda atada a la
experiencia del programador.

▪ Utilizan un único procesador en ambientes multiprocesador.

▪ Una Llamada al sistema bloqueante bloquea el LWP y su KLT asociado, por lo que ningún otro
hilo dependiente de este KLT podrá ejecutar, a menos que use Jacketing (técnica para poder
ejecutar hilos de usuario sin bloquear otros hilos de usuario).
Ventajas KLT: ▪ El proceso de usuario no se tiene que encargar de la planificación de los hilos.

▪ Si tenemos un procesador con más de un núcleo, el Sistema operativo puede planificar los
hilos en diferentes núcleos.

▪El bloqueo de un hilo no bloquea la ejecución del resto (ya que los ve el SO como procesos
ligeros separados).

Desventajas KLT: ▪Causan mayor Overhead en determinados modelos (Ej. Uno a Uno).

▪Limitados por la disponibilidad del manejo de hilos del SO. Muchos KLTs pueden causar
excesiva “sobrecarga” (Overhead).

▪Limitados a la aplicación o máquina utilizadas.

▪Mayor costo de creación y administración que los ULTs.

CONCURRENCIA

Nos paramos desde el lado del programador

Sección crítica: Sección de código dentro de un Proceso que requiere acceso a recursos
compartidos (datos y dirección de archivos) y que no debe ser ejecutada mientras otro proceso
se encuentre dentro de ésta misma sección de su código y en uso del recurso mencionado.
Cada proceso tiene una o más secciones críticas.

Condición de carrera: Situación en la cual múltiples KLTs o procesos leen y escriben un dato
compartido y el resultado final depende de la coordinación relativa de sus ejecuciones. Como
se vio en unidades anteriores, los Procesos “compiten” por los recursos. La condición de
carrera es la expresión de esta competencia y debe ser administrada para que los resultados
obtenidos no sean diferentes de los esperados.

Causas de la competencia

▪ Existencia de recursos compartidos

– Variables globales, regiones de Memoria Principal, Archivos, etc. Pueden ser accedidos por
diferentes procesos en un determinado momento.

– El procesador es un recurso compartido que también se gestiona (esta labor la realiza el

dispatcher, según la política de planificación establecida).

– Los dispositivos de E/S son recursos compartidos cuyo uso también debe ser controlado y
sincronizado.

▪ Forma en la que los procesos Colaboran o Compiten entre sí:

– Procesos no que se perciben entre sí (Independientes): Su relación es la competencia. Los

resultados de un proceso son independientes de la acción de los otros. Sus posibles problemas
de control son la exclusión mutua, el interbloqueo (rr) y la inanición.

– Procesos que se perciben indirectamente entre sí (Parcialmente colaborativos). Su relación

es la cooperación por compartición. Los resultados de un proceso pueden depender de la
información obtenida de otros. Sus posibles problemas de control son la exclusión mutua, el
interbloqueo (rr), la inanición y la coherencia de datos.

– Procesos que se perciben entre sí (Colaborativos): Su relación es la cooperación por

comunicación. Suelen ser procesos que corresponden a un mismo programa o conjunto de
programas que trabajan juntos. Los resultados de un proceso pueden depender de la
información obtenida de otros. Sus posibles problemas de control son el interbloqueo (rc) y la
inanición.

En todos los casos la temporización del proceso puede verse afectada.

Exclusión Mutua: Requisito de que cuando un proceso esté en una sección crítica que accede a
recursos compartidos, ningún otro proceso pueda estar en una sección crítica que acceda a
ninguno de estos recursos compartidos. Si un proceso no puede avanzar por la exclusión
mutua, debe bloquearse.

Atomicidad: Garantiza que una o más operaciones pueden ejecutarse en forma sucesiva sin ser
interrumpidas o temporizadas hasta haber finalizado (se apropian del procesador).

Requisitos para exclusión mutua

▪ Sólo un proceso/hilo puede encontrarse dentro de la sección crítica de su código que utiliza
un recurso compartido.

▪ Un proceso/hilo que se pare en su sección no crítica no debe interferir en ninguna forma con
otros procesos/hilos.

▪ No debe ser posible que un proceso/hilo que solicita acceso a su sección crítica sea
pospuesto indefinidamente.

▪ Cuando ningún proceso/hilo esté en la sección crítica, cualquiera de ellos (el primero en
solicitarlo) deberá poder acceder a la misma sin restricciones.

▪ Un proceso/hilo permanece dentro de su sección crítica sólo por un tiempo finito.

Semáforos

▪ Es una variable entera compartida que será utilizada para:

– Controlar el acceso a recursos compartidos.

– Resolver problemas de sincronización.

– Sus principales atributos son:

- Representan una cantidad o valor

-Tienen asociada una cola de procesos que esperan en el semáforo para acceder a una sección
crítica de su código. El semáforo sincroniza el uso de un recurso compartido.

▪ Operaciones con Semáforos: Ej. Sea “s” una variable semáforo:

– Signal(s) o Up(s): Al ser invocadas si s = 0, revisan la cola de procesos bloqueados por el

semáforo y despiertan al primero. Sino, incrementarán el valor de “s” en 1 (uno).

– Wait(s) o Down(s): las funciones decrementarán el valor de “s” en 1 (uno). Si s = 0 el proceso

invocando wait(s) o down(s) quedará bloqueado en la cola del semáforo, hasta que s > 0
Estas funciones son atómicas.

Semáforos binarios (mutex [mutual exclusion]): solo pueden valer 0 o 1

Semáforos contadores: pueden tomar valores positivos o negativos. Si es positivo, representa

las instancias disponibles en un recurso. Si es negativo, representa la cantidad de procesos o
hilos bloqueados en ese semáforo.

Es obligatorio inicializar los semáforos.

Si todos los procesos se llegan a ejecutar, el valor del semáforo al finalizar tiene que ser el
mismo que al comienzo.

Monitores: semáforos escritos en un lenguaje particular

Ejercicios con semáforos

Ejercicios de seguimiento: los más fáciles. Se parecen a los de planificación. Se nos da una
planificación y una sucesión de solicitudes de uso de primitivas de semáforos para manejar
procesos. Hay que seguir la tabla y decir en qué situación terminan los procesos.

Ejercicios de crear algoritmos.

Ejercicio de posicionar semáforos.

INTERBLOQUEO

Bloqueo permanente de dos o más procesos que poseen una serie de recursos asignados y
que, para continuar (y/o finalizar) con su ejecución, requieren recursos que actualmente están
asignados a otros procesos, cuando al mismo tiempo, éstos últimos requieren los recursos que
tienen asignados y en uso los primeros. No depende de la planificación. Depende de la
dinámica de la ejecución.

Recursos reutilizables: aquel que sólo un proceso puede utilizar en forma segura en un
determinado momento y que no se destruye después de su uso. Son limitados. Ejemplo:
memoria, disco, CPU, E/S.

Recursos consumibles: aquel que puede crearse (producirse) y destruirse (consumirse). No hay
límites para la creación de recursos consumibles. Ejemplo: interrupciones, señales, mensajes.

El interbloqueo se produce dentro de los recursos reutilizables, porque los consumibles se

pueden producir en base a la necesidad. Es decir, se pueden crear infinitamente.

Condiciones necesarias para un interbloqueo

-Exclusión mutua: Sólo un proceso puede utilizar un recurso en cada momento y no se permite
que otro recurso lo utilice.

-Retención y espera: Un proceso puede mantener los recursos que le son asignados mientras
espera la asignación de otros recursos.

-Sin desalojo de cualquier recurso: No se puede forzar la expropiación de un recurso a un

proceso que lo posee.

Condición suficiente para que exista interbloqueo

Espera circular: lista de procesos cerrada en la cual cada proceso posee al menos un recurso,
necesario por el siguiente proceso de la lista.

Hay interbloqueo => hay ME, SD y HW.

Hay Espera Circular => hay interbloqueo

Estrategias para tratamiento del Interbloqueo

Consiste en diseñar un sistema de manera que esté excluida la posibilidad de interbloqueo.

Existen dos métodos:

-Indirectos: impiden la aparición de ME, SD y HW.

-Directos: impiden la espera circular, ME, SD y HW.

Hay 3 estrategias:

Prevención (indirecto/directo)

Diseñar un SO que no permita la ocurrencia de las 4 condiciones que aseguran el interbloqueo.

Está basada en cuestiones de diseño. En la Prevención hay negar al menos una de las
condiciones necesarias.

– Negar la exclusión mutua: ▪ Imposible con recursos no compartibles (Ej.: impresoras)

– Negar el sin desalojo: ▪ Sólo para recursos que pueden recuperar su estado fácilmente (Ej.
memoria o CPU). Un proceso que tiene que esperar pierde los recursos que le fueron
asignados, y pasa a esperar también por ellos.

▪ Alternativamente, se demora la expropiación hasta que algún otro proceso necesite dichos
recursos. Riesgo de inanición

– Negar la retención y espera: ▪ Obligar a solicitar todos los recursos que vaya a necesitar cada
proceso al inicio de su ejecución. Problema: un proceso puede no conocer por adelantado
todos los recursos que va a necesitar (Ej. trabajos interactivos). Hay riesgo de inanición.
Recursos asignados que no se utilizan.

▪ Como alternativa, sólo permitir solicitudes si los procesos no tienen ningún recurso asignado.

– Negar la espera circular: ▪ Ordenar los recursos y exigir que se soliciten en orden creciente. ▪
Alternativamente, siendo i≤j, exigir que un proceso libere los ejemplares que tenga asignados
de Rj antes de solicitar ejemplares de Ri . Problema: recursos asignados que no se utilizan.

Resultados de estas políticas: mala performance del SO. Mucho overhead.

Predicción o evasión (directo)

Es puro overhead. “Piensa todo antes.” Se da una idea de cómo van a ocurrir las cosas y
plantea diferentes escenarios de ejecución, y elegir el que llegue a un resultado feliz.

Permite la existencia de 3 condiciones (las 3 primeras) pero evita la asignación de recursos si

considera que dicha asignación causará un interbloqueo.

–Impedir que se llegue a interbloqueo, explotando información a priori sobre las necesidades
de los procesos.
–Denegar solicitudes que se podrían conceder, para no depender de la dinámica de ejecución
de los procesos.

–Política ligeramente menos conservadora que la prevención

– Utiliza el Algoritmo del Banquero.

¿Cómo evade el interbloqueo?

▪ La ejecución de los procesos puede derivar en un Estado Seguro (Sin interbloqueo) o un

Estado Inseguro (cualquier estado que tenga cualquiera de las 4 condiciones).

▪ Para evitar llegar al interbloqueo, se fuerza la evolución por Estados Seguros:

– Análisis del peor caso: un estado es seguro si es posible encontrar un orden para satisfacer
las necesidades máximas de todos los procesos.

– Para un estado dado, una secuencia de procesos (p1, p2,..., pn) es una secuencia segura si las
necesidades máximas de Pj en ese momento pueden satisfacerse con los recursos libres más
los que tienen asignados los procesos Pi con i<j.

–Un estado es seguro si existe para él una secuencia segura (que todos los procesos se van a
ejecutar sin interbloqueos).

Estado seguro: No hay interbloqueo y se puede encontrar un orden para satisfacer las
necesidades máximas de todos los procesos.

Estado inseguro: Puede haber interbloqueo o no. De no haberlo ya, el que se llegue o no a
interbloqueo depende de cómo se sucedan las solicitudes de recursos.

Se encuentra estado seguro => secuencia segura.

Ningún paso de la secuencia se altera <=> no podrá hacerse inseguro.

Detección (directo) – Ley Marcial

El SO concederá a los procesos el uso de los recursos siempre que éste sea posible.
Periódicamente el SO verificará la existencia de una espera circular.

En caso de detectarla procederá a (según sea conveniente):

– Abortar todos los procesos involucrados en el interbloqueo

– Retroceder cada proceso a un punto de control (checkpoint) estable, previamente definido.

– Abortar sucesivamente los procesos hasta detectar la liberación del interbloqueo

– Expropiar sucesivamente los recursos para permitir la finalización de procesos, liberando los
que éstos tengan en uso, permitiendo así, el avance de los procesos bloqueados que los
requieren.
Algoritmo del banquero

▪ Se llama Algoritmo del banquero analogía con el funcionamiento de un banco. El banco

posee un capital fijo para “prestar” a sus clientes y necesita que cada préstamo sea devuelto,
antes de poder prestárselo a otros clientes. Con lo cual:

– Capital o dinero: Recursos disponibles (Reutilizables).

– Banquero: El SO que administra los recursos.

▪ El algoritmo se basa en:

– Conocer el número Máximo de recursos que cada proceso requerirá para su ejecución.

– Conocer el número de recursos que ya se encuentran Asignados a procesos existentes.

– El total de Recursos Disponibles en el sistema.

– El total de Recursos Disponibles en un determinado instante. (Antes de “prestar”)

– El cálculo de la Necesidad actual, resultante de restar Máximo – Asignado = Necesidad

Si el último proceso es el que no puede ejecutarse, no hay interbloqueo pero el estado no es

seguro, porque no todos los procesos llegan a feliz puerto.