El sistema operativo: gestión de procesos - oposcaib

El sistema operativo: gestión de procesos
El sistema operativo: gestión de procesos
Índice de contenido
El sistema operativo: gestión de procesos.....................................................................................................1
Licencia......................................................................................................................................................1
Introducción...............................................................................................................................................1
Evolución histórica.................................................................................................................................1
Concepto de proceso..............................................................................................................................1
Ciclo de vida de un proceso........................................................................................................................2
Modelos de 5 y 7 estados.......................................................................................................................2
Planificación de procesos.......................................................................................................................4
Threads.......................................................................................................................................................5
Problemas de los sistemas multiproceso....................................................................................................5
Exclusión mutua.....................................................................................................................................6
Soluciones.........................................................................................................................................6
Interbloqueos..........................................................................................................................................6
Soluciones.........................................................................................................................................7
Inanición.................................................................................................................................................7
Licencia
Este obra de Jesús Jiménez Herranz está bajo una licencia Creative Commons AtribuciónLicenciarIgual 3.0 España.
Basada en una obra en oposcaib.wikispaces.com.
Introducción
Evolución histórica
Históricamente, los sistemas han evolucionado en la siguiente progresión:
●
●
●
●
Proceso en serie: Los programas se introducían de forma manual en el ordenador. No hay
multiprogramación.
Proceso batch: Se establece un sistema para encolar los programas y que se ejecuten en
sucesión. Sigue sin haber multiprogramación.
Batch con multiprogramación: Para aprovechar mejor la CPU, cuando un programa del proceso
batch ejecuta una operación de E/S, se conmuta a otro programa hasta que ésta acabe.
Tiempo compartido: Se divide el tiempo de CPU en pequeñas fracciones, asignándose cada una
de ellas a un programa. De esta manera se simula la ejecución en paralelo de todos los
programas.
Concepto de proceso
Si bien en la literatura se encuentran muchas definiciones, se puede decir que un proceso es el
conjunto de datos que representa a un programa en ejecución. Tiene sentido hablar de procesos en
entornos de multiprogramación, en los que hay varios programas ejecutándose pseudosimultáneamente. Cada uno de estos programas está representado mediante un proceso.
Un proceso se compone de:
●
●
●
Código ejecutable: Instrucciones que ejecuta el programa.
Datos de programa: Variables que usará el programa en su ejecución.
Contexto: Estado de la CPU, así como otras informaciones relevantes para describir al proceso.
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
1
El sistema operativo: gestión de procesos
La disposición de los programas en memoria sería la siguiente:
RAM
CPU
Planificador
PC
Proceso 1
Proceso 2
Proceso 3
Como se puede ver, en memoria estarían cargados los diferentes procesos, con su código, datos e
información de contexto. Un proceso adicional, perteneciente en este caso al sistema operativo,
sería el planificador, que se encargaría de decidir qué proceso debe ejecutarse en un momento dado.
Todo este procedimiento se implementaría alterando convenientemente el registro PC de la CPU,
que contiene la dirección de la siguiente instrucción a ejecutar.
Ciclo de vida de un proceso
Modelos de 5 y 7 estados
Los diferentes estados en los que puede estar un proceso se ven representados en el siguiente
diagrama:
Nuevo
Terminado
Cargado
Fin
ejecución o
error
Inicio quantum
Listo
Fin quantum
Fin
operación
E/S
Ejecución
Operación
E/S
Bloqueado
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
2
El sistema operativo: gestión de procesos
Así, los procesos se inician con la carga del programa, y a continuación quedan esperando a que
se les asigne la CPU (listo). En ese momento se empiezan a ejecutar, momento en el cual pueden
pasar dos cosas: que se acabe su quantum de CPU, en cuyo caso vuelven a esperar al siguiente, o
bien que ejecuten una operación de E/S. En este último caso el proceso pasa a estado de espera de
E/S (bloqueado) y abandona la CPU. Cuando la operación de E/S ha terminado, y por tanto el
proceso está en disposición de ejecutar más código, vuelve al estado listo.
Una implementación de este esquema podría ser la siguiente:
Listos
Fin
CPU
Inicio
Fin del quantum
Operación
de E/S
Bloqueados
Fin de E/S
En este esquema, los procesos que llegan al sistema se van encolando, y son atendidos en orden
por la CPU. Si, una vez en la CPU, el proceso agota su quantum, vuelve a ser encolado en la cola de
listos. Si por el contrario ejecuta una operación de E/S, pasa a otra cola, la de bloqueados, en la que
se encolarían los procesos que están esperando para alguna operación de E/S. Una vez obtenido su
turno y ejecutada la operación, el proceso volvería a la cola de listos. Si bien en el esquema se
muestra una única cola de bloqueados, en realidad debería haber tantas como dispositivos de E/S
existan en el sistema.
Un modelo que representa de forma más compleja el ciclo de vida de los procesos es el siguiente,
que contempla la posibilidad de descargar los procesos menos usados a disco para ahorrar memoria:
Nuevo
Terminado
Fin
ejecución o
error
Cargado
Poca RAM
o prioridad
Listo susp.
Inicio quantum
No hay listos
en RAM
Fin
operación
E/S
Listo
Fin quantum
Fin
operación
E/S
Ejecución
Operación
E/S
RAM libre
Bloq. susp.
Poca RAM
Bloqueado
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
3
El sistema operativo: gestión de procesos
En este caso, además de los estados del modelo anterior, se añaden dos adicionales: Listosuspendido y Bloqueado-suspendido. La diferencia entre estos estados y sus equivalentes no
suspendidos es que en estos últimos el proceso se encuentra en memoria, mientras que en los
suspendidos se ha descargado a disco. De esta manera es posible ahorrar memoria (que suele ser un
recurso escaso).
En este modelo, la idea es tener el máximo número de procesos en memoria, tanto listos como
bloqueados. Ahora bien, cuando la memoria escasea, la primera medida es descargar a disco a
procesos bloqueados. Si aún hay necesidad de memoria, y no hay ningún proceso bloqueado en
memoria, se empiezan a descargar los procesos listos. Conforme se vaya liberando memoria, los
procesos suspendidos irán siendo recargados.
Es importante planificar cuidadosamente la política de carga y descarga de procesos, intentando
descargar a disco procesos para los que no se prevea que entren en la CPU a corto plazo. En caso
contrario, se podrían producir ciclos de lecturas y escrituras que ralentizarían considerablemente el
sistema (hiperpaginación).
Planificación de procesos
En un sistema multiprogramado, en el que hay varios procesos en ejecución, la política que
definirá a qué proceso se le asigna la CPU en un momento dado es crucial para el buen rendimiento
del sistema. Básicamente existen los siguiente esquemas:
●
●
●
FIFO: Los procesos se ejecutan en orden de llegada. Tiene el problema de que ralentiza en
exceso a los procesos cortos.
Primero el más corto: En cada momento, se envía a la CPU el proceso más corto. Mejora el
tiempo de respuesta, pero es poco predecible (no es trivial determinar si un proceso es corto) y
puede provocar inanición.
Round-robbin: Se establece un tiempo (quantum) para cada proceso, al final del cual debe ceder
la CPU para ser asignada a otro proceso. Si el quantum es pequeño, se simula el efecto de la
ejecución simultánea de todos los procesos. Es un buen esquema de propósito general, aunque
sin una buena gestión de prioridades tiende a marginar a los procesos que usan mucha E/S.
Para implementar diferentes niveles de prioridad en el sistema, se puede establecer un esquema
como el siguiente:
Listos - 0
Listos - 1
CPU
Inicio
Fin
Listos - 2
Fin del quantum
Operación
de E/S
Bloqueados
Fin de E/S
En este caso, en vez de disponer de una cola de listos, existirían diferentes colas, cada una
correspondiente a una prioridad. El planificador del sistema, a la hora de seleccionar el proceso a
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
4
El sistema operativo: gestión de procesos
ejecutar en el siguiente quantum, buscaría en primer lugar entre los procesos de la cola 0. Si allí no
hay procesos listos, buscaría en la 1, y así sucesivamente. De esta manera, se implementa un sistema
de prioridades en el que los procesos más prioritarios podrán disponer de la CPU con preferencia
respecto a los de baja prioridad.
La prioridad de un proceso puede ser fija (asignada en el momento de la carga) o bien puede ir
variando durante la ejecución. Así, una política común para mejorar el comportamiento del sistema
es alterar la prioridad de los procesos según su comportamiento. Por ejemplo, si un proceso ha
usado sólo parte de su quantum debido a que se ha bloqueado por una operación de E/S, se le
aumenta la prioridad. Por el contrario, si ha agotado su quantum, su prioridad disminuye. De esta
manera, se mejora el tiempo de respuesta para los procesos de E/S, que sólo usan la CPU
esporádicamente, sin ralentizar en exceso los procesos de cálculo, ya que los procesos que les
adelantan liberan en seguida la CPU.
Threads
Si bien los procesos son un mecanismo imprescindible para conseguir un sistema operativo
multiprogramado, también es cierto que tienen una serie de inconvenientes:
●
●
Overhead: La gestión de procesos tiene asociado un overhead importante en lo que respecta a la
gestión de su contexto.
Dificultad de comunicación: La gran independencia de los procesos entre sí obliga a utilizar
mecanismos de comunicación generalmente complejos para que los diferentes procesos
intercambien información.
Por estos motivos, y para las ocasiones en los que los procesos resultan demasiado complejos, la
mayoría de sistemas operativos soportan lo que se conoce como hilos o threads. La diferencia
respecto a los procesos es que todos los hilos de un mismo proceso comparten el mismo contexto,
es decir, espacio de direcciones y variables, y asignación de recursos. Ventajas e inconvenientes:
Ventajas
●
●
Cambios de contexto extremadamente
rápidos
Comunicación entre threads sencilla
Inconvenientes
●
Mayores problemas de concurrencia:
interbloqueos, exclusión mutua, etc.
Problemas de los sistemas multiproceso
El hecho de ejecutar varios procesos a la vez, compartiendo por tanto los recursos de la máquina,
da lugar a diferentes problemas:
●
●
●
Exclusión mutua: Es difícil garantizar que sólo accederá un proceso a la vez a un recurso dado.
Interbloqueos: Si hay interdependencias entre las necesidades de recursos de dos procesos,
pueden producirse situaciones de espera infinita.
Inanición: La existencia de procesos de diferentes prioridades puede dar lugar a que algunos
procesos no reciban tiempo de CPU al estar permanentemente superados por otros de mayor
prioridad.
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
5
El sistema operativo: gestión de procesos
Exclusión mutua
Cuando dos procesos diferentes acceden al mismo recurso, hay que controlar quién está
accediendo en cada momento, ya que de lo contrario se pueden dar situaciones peligrosas. Por ello,
es necesario utilizar técnicas que garanticen que sólo un proceso está accediendo a un recurso dado
(región crítica) en cada momento.
Soluciones
Para conseguir la exclusión mutua en el acceso a un recurso, hay básicamente dos enfoques:
utilizar algoritmos que organicen el acceso a los recursos de forma ordenada, o bien utilizar
mecanismos provistos por el sistema operativo. Los diferentes algoritmos para conseguir la
exclusión mutua son:
●
●
●
Algoritmo de Dekker: Usar un flag para indicar la intención de entrar en la sección crítica. A
continuación, si el turno es de otro proceso, abandonar la intención hasta que el otro proceso
haya acabado. En ese momento ya podemos entrar a la región crítica.
Algoritmo de Peterson: Versión simplificada del anterior. Consiste en establecer el flag de
intención, y a continuación dar el turno al otro proceso hasta que lo suelte. En ese momento ya
podemos entrar en la región crítica.
Algoritmo de la panadería: Consiste básicamente en asignar a los procesos un número que
indicará el orden de acceso. A partir de ahí, los procesos esperarán hasta que sea su turno.
Si bien estos algoritmos pueden garantizar la exclusión mutua, generalmente implican que el
proceso espere de forma activa, lo cual es ineficiente desde el punto de vista de la CPU. Por tanto, el
sistema más utilizado consiste en usar diferentes mecanismos provistos por el propio sistema
operativo:
●
●
●
Semáforos: Es un TAD con dos operaciones atómicas: wait (P) y signal (V), y un parámetro, su
tamaño. Básicamente un semáforo es una variable que se incrementa con wait() y se decrementa
con signal(). Si al hacer wait() el valor interno iguala o supera al tamaño, se proceso queda
bloqueado hasta que otro proceso hace un signal(). De esta manera, si N procesos hacen wait()
de un semáforo de tamaño M antes de entrar a la región crítica, se garantiza que sólo entrarán a
la región crítica M procesos simultáneamente. Para un M=1, se dice que es un semáforo binario.
Monitores: Son estructuras que integran los datos objeto de la exclusión mutua con las
operaciones que los manipulan. Por la estructura de los monitores, se garantiza la ordenación de
las ejecuciones de las operaciones, así como la exclusión mutua en el acceso. Usando monitores,
la mayor parte del código destinado a sincronización queda encapsulado dentro del propio
monitor, por lo que es un mecanismo más limpio y escalable que los semáforos.
Paso de mensajes: En sistemas en los que la implementación de mecanismos como semáforos
no es trivial, como por ejemplo en sistemas distribuidos, se utiliza el paso de mensajes como
forma de sincronización. En este esquema, cualquier proceso utiliza dos operaciones: send() y
receive(), que permiten el intercambio de información y la sincronización de operaciones.
Interbloqueos
Un interbloqueo o deadlock se da cuando dos procesos esperan mutuamente a que el otro libere
un recurso para continuar. Como ambos están esperando al otro para liberar el recurso, la espera es
infinita y los procesos quedan bloqueados. Si en el proceso participan más de dos procesos, se
conoce como espera circular.
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
6
El sistema operativo: gestión de procesos
Las condiciones para que se dé un interbloqueo son:
●
●
●
Exclusión mutua: Un proceso debe poder reservar en exclusiva un recurso
Reserva múltiple: Los procesos deben poder reservar en exclusiva más de un recurso a la vez
Espera circular: Los procesos involucrados deben tener un recurso asignado, y estar esperando
para el recurso reservado del siguiente. El último proceso de la cadena debe estar solicitando el
recurso del primero
Soluciones
Algunas soluciones a los interbloqueos son:
●
●
●
●
●
Liberación ante denegación: Si un proceso con un recurso asignado pide otro, y se le deniega,
está obligado a liberar todos los recursos
Prioridad: En caso de interbloqueo, el proceso de menor prioridad debe ceder y liberar su
recurso en favor del de mayor prioridad. Al igual que el anterior, sólo es aplicable con recursos
fácilmente liberables.
Ordenación de recursos: Ordenar linealmente los recursos, e impedir peticiones de recursos con
un identificador menor a los ya asignados. Elimina los interbloqueos, pero impide también
muchos accesos legítimos.
Grafo de dependencias: Construir un grafo con las dependencias entre procesos para detectar
ciclos y resolverlos mediante la anulación de los procesos que provocan el interbloqueo.
Algoritmo del banquero: Algoritmo que lleva un control sobre el estado del sistema en lo que
respecta a la asignación de recursos. Así, cada proceso informa al iniciarse la cantidad máxima
de recursos que va a utilizar. A partir de ahí, en cada petición de recursos el sistema analiza si
esa asignación puede llevar a un estado “inseguro”, es decir, desde el que (teniendo en cuenta la
previsión de consumo de recursos) se puede llegar a un interbloqueo. Si es así, no autoriza la
petición. Dado que generalmente no es posible prever el consumo de recursos de un proceso, no
es un método demasiado factible.
Dado que ninguna de estas soluciones es infalible, el mejor resultado se consigue combinando
diferentes técnicas.
Inanición
La inanición se da cuando un proceso ve negado perpetuamente el acceso a un recurso, por lo
que nunca puede finalizar su ejecución. Esto se debe generalmente a la ejecución de otros procesos
con mayor prioridad a los que siempre se les asignan los recursos.
Un caso especial de inanición se da cuando a un proceso C se le niega el acceso a un recurso en
favor de B, un proceso de mayor prioridad. Si además C es el responsable de un resultado por el que
está esperando A, un proceso de mayor prioridad aún que B y C, sucederá que A sufrirá inanición a
pesar de ser el proceso de mayor prioridad del sistema. Esto se conoce como inversión de
prioridades.
La solución a la inanición pasa por establecer mecanismos que asignen una cantidad mínima de
cada recurso a todos los procesos, independientemente del sistema de prioridades.
Jesús Jiménez Herranz, http://oposcaib.wikispaces.com
7