Está en la página 1de 7

Cosas que hace el SO:

● Provee abstracciones que simplifican el uso de las interfaces que los


programadores y los programas de aplicación deben usar para comunicarse
con el hardware.
● Asigna y administra los recursos de hardware de manera eficiente y
equitativa entre las diferentes aplicaciones que necesitan utilizarlos, evitando
conflictos y asignando prioridades según sea necesario.
● Provee un entorno a los usuarios para ejecutar programas de una forma
conveniente y eficiente
● Como programa de control: supervisa la ejecución de programas de usuario
para prevenir errores y uso inapropiado de la computadora, gestiona la
operación y control de los dispositivos de E/S.

Multiprogramación: el SO mantiene varios procesos cargados en memoria de


modo que cuando un proceso necesita esperar por algún evento como por ejemplo
E/S, en lugar de que el procesador se quede esperando a que el evento ocurra, el
SO cambia y ejecuta otro proceso para mantener ocupado al CPU.

Multitarea: funciona como la multiprogramación, pero los cambios entre procesos


son mucho más frecuentes lo cual provee un rápido tiempo de respuesta.

Tiempo compartido: es una variante de la multiprogramación la cual permite que


múltiples usuarios desde su propia terminal puedan correr procesos
concurrentemente.

Interrupciones y traps:

Las interrupciones son señales que el hardware envía a través del sistema para
alertar al CPU de eventos que requieren atención y permitiéndole responder a
eventos asíncronos. Cuando el CPU es interrumpido, este deja de hacer lo que
estaba haciendo y le transfiere el control a la rutina del controlador de interrupciones
correspondiente.

Los traps son interrupciones generadas por software y pueden ser causadas por un
error (por ejemplo, división por cero) o un requerimiento de un programa de usuario
a través de una llamada al sistema.
Deadlocks

Un deadlock puede ocurrir si las siguientes 4 condiciones existen simultáneamente


en un sistema:
● Exclusión mutua: sólo un proceso puede usar un recurso a la vez, si otro lo
necesita debe esperar a que el primero lo libere.
● Retener y esperar: un proceso debe estar reteniendo un recurso, mientras
está esperando por otro recurso retenido por otro proceso.
● No apropiación: los recursos no se pueden apropiar, solo pueden ser
liberados voluntariamente por el proceso que lo estaba reteniendo luego de
terminar de usarlo.
● Espera circular: debe existir un conjunto de procesos {P0, P1, Pn} tal que P0
espera a que P1 libere un recurso, P1 espera a que P2 libere un recurso, …,
Pn espera a que P0 libere un recurso.

Grafo de alocación de recursos

Consiste de un conjunto de vértices para los procesos {P0, P1, …, Pn} y un conjunto
de vértices para los recursos {R0, R1, …, Rn}. Y las aristas Pi → Ri (aristas de
solicitud) si Pi requiere una instancia de Ri y Ri → Pi (aristas de asignación) si el
recurso Ri fue asignado al proceso Pi.
Si el grafo no contiene ciclos, entonces no hay deadlock.
Si el grafo contiene un ciclo, entonces puede existir deadlock, según la cantidad de
recursos que hayan en los conjuntos Ri implicados en el ciclo.

Prevención de deadlocks
Se asegura que al menos una de las 4 condiciones necesarias para un deadlock no
se cumplan. Se hace mediante un ordenamiento de los recursos, asociándole a
cada recurso Ri un valor entero tal que Ri < Ri+1, al momento de pedir bloqueos
solo se puede hacer de manera ascendente y si se requiere cierto recurso se deben
liberar todos los recursos de orden mayor.
Esto puede generar baja utilización de dispositivos y throughput del sistema.

Evitación de deadlocks
El SO necesita conocer qué recursos va a requerir cada proceso, en qué orden y
cuándo los va a liberar, así al momento de cada requerimiento, el SO puede decidir
si el mismo puede ser satisfecho o no.
Estado seguro
Un estado de alocación de recursos se define por la cantidad de recursos libres,
alocados y la necesidad máxima de cada proceso sobre cada recurso.
Un estado se dice seguro si el sistema puede alocar recursos en algún orden para
evitar un posible deadlock (si existe una secuencia segura, es decir una secuencia
<P1, P2, Pn> tal que las necesidades de cada Pi pueden ser satisfechas por los
recursos libres actuales más los liberados por todo Pj tal que j<i).
Si un estado es seguro, entonces no hay deadlocks. Sin embargo, en un estado
inseguro puede haber o no. Baja utilización de recursos.

Algoritmo estado seguro

1. Crear un vector ‘Work’ igual al vector de recursos disponibles y un vector


‘Finish’[n] siendo n la cantidad de procesos inicializado en F para todo n.
2. Buscar un n tal que Finish[n] = F y el vector de necesidad de n sea menor al
vector Work. Si se encuentra, pasar a 3, sino pasar a 4.
3. Work = Work + el vector de alocados de n.
Finish[n] = V. Volver a 2.
4. Si para todo n Finish[n] = V, entonces el sistema está en un estado seguro.

Algoritmo de requerimiento de recursos


1. Crear un vector Request con los valores de los recursos que el proceso está
requiriendo.
2. Si Request <= Necesidad, ir al paso 3. Sino error.
3. Si Request <= Disponible, ir al paso 4. Sino esperar.
4. Disponible = Disponible - Request.
Alocados = Alocados + Request
Necesidad = Necesidad - Request.
5. Chequear el estado, si es seguro se efectúa el requerimiento, sino se vuelve
al estado anterior.

Detección de deadlocks

Grafo wait-for.

1. Crear un vector ‘Work’ igual al vector de recursos disponibles y un vector


‘Finish’[n] siendo n la cantidad de procesos inicializado en F para todo n si
Alocados[n] != 0.
2. Buscar un n tal que Finish[n] = F y el vector de necesidad de n sea menor al
vector Work. Si se encuentra, pasar a 3, sino pasar a 4.
3. Work = Work + el vector de alocados de n.
Finish[n] = V. Volver a 2.
4. Si Finish[n] = F, para algún n, entonces el sistema está en deadlock y el
proceso n está interbloqueado.
Recuperación de deadlocks

Mediante terminación de procesos:


● Abortar todos los procesos que estén en deadlock.
● Abortar uno por uno hasta que se resuelva el deadlock.
● Para elegir qué proceso abortar se debe tener en cuenta su prioridad, durante
cuánto tiempo estuvo activo, qué recursos usó, qué recursos necesita…

Mediante apropiación de recursos:


● Seleccionar una víctima: qué recursos de qué procesos van a ser apropiados.
● Roll-back: si se apropian recursos de un proceso, este debe ser retornado a
un estado seguro y reiniciarlo desde ese estado (o simplemente abortarlo y
reiniciarlo desde el principio).
● Inanición: incluir el número de rollbacks como parte del costo a la hora de
seleccionar un proceso para ser “víctima”.

Planificación de CPU

Planificador de corto término: elige de la cola de listos el próximo proceso a ejecutar.


Se invoca cuando el procesos actual termina, se bloquea o hay una oportunidad
para apropiarlo (ya sea por quantum o por que llega un proceso con mayor
prioridad).

Planificar de mediano término: se encarga de la función de swapping, mover


procesos desde y hacia los estados de listo, listo/suspendido, bloqueado,
bloqueado/suspendido.

Planificador de largo término: se encarga de elegir si un proceso nuevo puede entrar


a la cola de listo, controlando así el grado de multiprogramación.

Turnaround time (tiempo de retorno): el tiempo que pasa desde que un proceso
llega al sistema hasta que es completado. Es la suma del tiempo que el proceso
pasa esperando en la cola de listos, haciendo E/S y ejecutando.

Tiempo de espera: es la suma de los tiempos que el proceso pasa en la cola de


listos.

Tiempo de respuesta: es el tiempo que pasa desde que el proceso llega al sistema
hasta que comienza a ejecutar.

FCFS: es el más simple. Se implementa con una cola de listos FIFO, en la cual el
primer proceso que llega es el primero al que se le concede el CPU, no hay
apropiación así que cada proceso ejecuta hasta terminar o hasta ser bloqueado por
algún evento. Alto tiempo de espera promedio, efecto convoy y baja utilización de
CPU y dispositivos.

SJF: le asocia a cada proceso el tiempo de su próxima ráfaga de CPU, cuando el


CPU está libre, este se le asigna al proceso cuya próxima ráfaga es la menor, si hay
más de uno se usa FCFS. Mínimo tiempo de espera promedio. No se puede
implementar ya que no hay forma de saber el tiempo de la próxima ráfaga de CPU
de un proceso. Puede ser apropiativo o no apropiativo.

RR: se define un time quantum y la cola de listos se toma como una cola circular. El
CPU toma el primer proceso de la cola y pasado el time quantum, cambia al próximo
proceso en la cola. Es apropiativo. Alto tiempo de espera promedio.

Prioridades: a cada proceso se le asocia una prioridad. Siempre se busca ejecutar


el proceso de mayor prioridad, si hay más de uno con la misma prioridad se usa
FCFS. Puede ser apropiativo o no apropiativo. Riesgo de inanición.

Colas multinivel: se tienen colas de listos distintas para cada prioridad y se toman
procesos de la cola con mayor prioridad que tenga algún proceso. Además, cada
cola puede planificarse de una forma distinta, por ejemplo RR o FCSF, dependiendo
de si se las separa por tipo de proceso.

Colas de retroalimentación multinivel: es igual a las colas multinivel, pero permite


que los procesos puedan moverse entre las colas, con la idea de ir bajándoles la
prioridad a los procesos que requieran mayor tiempo de CPU y también poder
subirle la prioridad a aquellos procesos que hayan estado mucho tiempo en las
colas de menor prioridad para prevenir inanición.

Planificación de hilos

En muchos a muchos o muchos a uno, los hilos a nivel de usuario son manejados
por una librería de hilos y el kernel no sabe de su existencia, mientras que los hilos
a nivel de kernel son manejados directamente por el SO. Los hilos de kernel son
más costosos de mantener ya que deben estar asociados a una estructura de datos
del kernel.

Planificación de multiprocesadores

Multiprocesamiento asimétrico: un único procesador se encarga de las decisiones


de planificación y otras actividades del sistema, mientras que los demás
procesadores solo ejecutan código de usuario. Solo un procesador accede a las
estructuras del sistema, no es necesario compartir datos. Este procesador central
puede ser un cuello de botella para el rendimiento general del sistema.
Multiprocesamiento simétrico: cada procesador maneja su propia planificación.
Se puede tener una cola de procesos compartida entre todos los procesadores, pero
puede generar condiciones de carrera por lo que se necesita algún método de
sincronización reduciendo el rendimiento del sistema, o se puede tener una cola de
listos privada para cada procesador.

Una de las complicaciones del multiprocesamiento asimétrico con colas únicas por
cada procesador es balancear la carga, esto se puede hacer mediante
● Push migration: periódicamente se evalúan las cargas de los procesadores y
cuando se encuentra un desequilibrio, se envían procesos desde el
procesador más cargado al menos cargado.
● Pull migration: un procesador desocupado toma procesos de otro más
cargado.

Tiempo real blando: asegura que las tareas críticas tendrán prioridad sobre las no
críticas, pero no garantiza nada sobre cuándo se ejecutará.

Tiempo real duro: requiere que las tareas críticas se completen sí o sí antes de su
deadline.

Rate Monotonic: a cada proceso se le asigna una prioridad según la longitud de su


período, a menor período, mayor prioridad. Primero se calcula la utilización de CPU
para ver si sería posible planificar los procesos, esto es, para cada proceso se
calcula ráfaga de CPU/período y se suman todos los resultados, lo cual debería ser
menor a 1. Si un proceso está ejecutando su ráfaga de CPU y el período de otro con
mayor prioridad vuelve a empezar, el mismo apropia la CPU.

EDF: asigna prioridades dinámicamente de acuerdo al deadline de cada proceso,


mientras más cerca esté el deadline, mayor prioridad.

Sincronización
Condición de carrera: cuando dos o más procesos están leyendo y/o escribiendo un
dato compartido y el resultado depende del orden en que se ejecutaron los
procesos.

Sección crítica: es la parte del programa en la cual el proceso accede al dato o los
datos compartidos

Condiciones para una buena solución al problema de la sección crítica


● Exclusión mutua: no pueden haber 2 procesos en su sección crítica
simultáneamente.
● Progreso: un proceso que no esté en su sección crítica no debe bloquear a
otro proceso.
● Espera limitada: ningún proceso debería esperar indefinidamente para poder
entrar a su sección crítica.

También podría gustarte