GESTION DE PROCESOS
.png)
Cuaderno completo con este tema:
https://notebooklm.google.com/notebook/8c2f2e3a-f6da-4338-9f1f-8851322f74aa
Esta es la tarea central en el núcleo de un sistema operativo multitarea.
Abarca la gestión del recurso fundamental, la CPU.
El multinúcleo no hace a la gestión de CPU, pues es manejado explícitamente por el usuario.
El sistema operativo no puede decidir si paralelizar un código sin más…
Miren este caso:
a=x+1
b=y+1
c=a-b
d=c/2
no puedo mandar ese código “así nomás” a 4 núcleos, pues tenemos las siguientes precedencias:
c necesita que a esté terminado
c necesita que b esté terminado
d necesita que c esté terminado
El óptimo, en multinúcleo sería:
a=x+1 NUCLEO 1
b=y+1 NUCLEO 2
esperar a que a que a y b terminen
c=a-b NUCLEO 1
esperar a que C termine
d=c/2 NUCLEO 1
Este problema, que acá optimizamos manualmente, no puede ser resuelto en forma automática por una computadora.
O sea, no hay forma de que el sistema operativo mande a diferentes núcleos código por el simple hecho de haberlo analizado línea a línea. Ese problema no es computable.
Esto constituye una limitación.
El multinúcleo, el sistema operativo lo gestionará en la medida que el programador lo explicite. Y esto es mucho! Pero no es tanto como una gestión automática por parte del sistema operativo.
La variable que nosotros podemos manejar, nosotros el sistema operativo, en el schedulling es fundamentalmente, a qué proceso le damos el procesador, cuando se lo quitamos, a quién le toca de nuevo, etc.
Modelos de procesos
Un trabajo, es un programa que aún no ha sido ejecutado. Una vez en ejecución, se transforma en un proceso. Tarea y proceso son sinónimos.
La CPU se va a compartir en forma secuencial a lo largo del tiempo por los procesos.
El modelo primero se llama FIFO. Tendría sentido para un sistema tipo Batch.
El segundo modelo es tal que vamos ejecutando concurrentemente y guardando los contadores de programa. Si bien volveremos sobre más modelos, a continuación avanzamos en este último.
Lo que sigue explica cómo se reparte la CPU en un SO multitarea.
Los procesos que podrían recibir CPU, los llamamos LISTOS. Se alojan todos en memoria, y comienza el SCHEDULLING. (consumen memoria desde este momento)
Se le da la CPU al primero de ellos, que pasa a estar EN EJECUCIÓN.
Entonces, comienza un proceso, el resto se coloca en fila tras él.
Este proceso computa hasta que realiza alguna operación de E/S. Esta operación, implica esperar por una interrupción. Como esta demora “una eternidad”, respecto a la velocidad de CPU, entonces hay que cederle la CPU a otro proceso. Al siguiente de la fila!
Qué pasa con este proceso que venía ejecutando ? Pasa a un estado de espera, el cual llamaremos BLOQUEADO. Ahí no consume CPU porque está esperando una interrupción. Y además él está fuera de la fila de espera.
Ejemplo de E/S: leer de teclado, escribir en pantalla, imprimir, guardar en disco, leer de disco, etc.
También podría pasar, que el proceso no haga ninguna operación de E/S, se pasa haciendo cálculos, cuentas!, en tal caso va a acaparar la CPU, y esto no es deseable. Existe entonces un timeout, que es un tiempo máximo de espera el cual, si se alcanza, se acaba el tiempo para este proceso y le toca a otro. A cuál ? Al siguiente en la fila.
Qué pasa con el proceso al cual se le quitó la CPU por timeout ? No espera ninguna interrupción porque no está haciendo una E/S, simplemente le falta CPU para continuar. Se lo coloca al final de la lista de procesos listos.
Qué pasa cuando un proceso bloqueado, recibe la indicación, por medio de una interrupción, de que la operación por la cual esperaba está lista ? Se lo coloca al final de la fila de listos y queda pronto para continuar el juego de reparto de procesador.
Esos son los 3 estados que describen los procesos.
El tiempo de timeout suele llamarse quantum (cuanto) de tiempo.
Esta forma de repartir la CPU se llama Round Robin (RR).
Es la base de la ilusión de la multitarea.
Luego como política de reparto de CPU la criticaremos, más adelante. No es apta para STR porque puede haber grandes esperas. Pero sí es apta para sistemas de tiempo compartido.
Es lo que utiliza Windows, Linux, etc. Android y IOS tienen una componente de tiempo real sobre este round robin (RR con prioridades).
Muy importante.
La arquitectura, es monotarea, funciona sin enterarse de que estamos ejecutando múltiples tareas. Esta ilusión del multitasking debe garantizar que la arquitectura “no se entere”.
Usaremos la técnica llamada GUARDAR EL CONTEXTO.
Esto es: cada vez que le vamos a quitar la CPU a un proceso (o sea cuando hizo el timeout o hizo E/S) debemos GUARDAR EL CONTEXTO, es decir, guardar una copia de CADA REGISTRO, en memoria.
Los procesos bloqueados estarán marcados como que esperan una interrupción. No integran la fila de ejecución.
Los procesos listos están marcados como que sólo les falta la CPU, e integran la fila de ejecución.
Esta área donde se guardan los registros y otros datos relevantes de cada proceso se llama PROCESS CONTROL BLOCK, PCB. Hay uno por cada proceso y están usualmente encadenados en una lista. Como su cantidad es incierta y variable, no podrían estar en un array, es necesaria una estructura dinámica.
A la operación FUNDAMENTAL de dar CPU a un proceso LISTO, se le llama DESPACHO.
Tenemos como operaciones relevantes sobre procesos:
- COMENZAR. Va al estado LISTO.
- TERMINAR. Se va del estado EN EJECUCION a FIN .
- DESPACHO. Va de listo a en ejecución
- BLOQUEO. Va de en ejecución a bloqueado.
- DESPERTAR. Va de bloqueado a listo.
- TIMEOUT. Va de en ejecución a listo.
En un momento dado, el sistema está gestionando N procesos, de los cuales 1 estará en ejecución (tal vez más de uno si hay una ejecución multinúcleo explícita) , varios estarán listos, y varios estarán bloqueados. Los listos van en una fila.
En caso de existir un esquema de prioridades podría ser que algunos procesos se adelanten en la lista.
Un proceso listo tan sólo necesita procesador para ejecutar.
En un momento dado, el sistema está gestionando N procesos, de los cuales 1 estará en ejecución (tal vez más de uno si hay una ejecución multinúcleo explícita) , varios estarán listos, y varios estarán bloqueados. Los listos van en una fila.
- N procesos en total.
- P procesos en ejecución (p mayor a 1 si hay multinúcleo)
- B procesos bloqueados
- L procesos listos
Entonces se cumple:
- N=P+B+L
En caso de existir un esquema de prioridades podría ser que algunos procesos se adelanten en la lista.
Un proceso listo tan sólo necesita procesador para ejecutar.
Las estructuras fundamentales del SO, como gestor de recursos son las listas de PCBs y RCBs.
- PCB Process Control Block
- RCB Resource Control Block
Son estructuras dinámicas, pues no podemos saber a priori la cantidad de recursos o de procesos que habrá.
Normalmente son listas doblemente enlazadas.
PCB
Es la estructura que caracteriza al proceso frente al SO.
Normalmente tienen:
- Identificador del proceso (PID). Un número, es lo más eficiente.
- Estado actual.
- Id del proceso en el sistema. Un número, por ejemplo en Linux se lo llama pid.
- Puntero al padre.
- Punteros a los procesos hijos.
- Prioridad del proceso.
- Punteros a las zonas de memoria asignadas al proceso. Se llama espacio de direcciones de memoria.
- Punteros a los recursos asignados al proceso. Una lista. Funciona como un hilvanamiento sobre los RCBs.
- Área para salvaguardar registros. Esta contiene los valores de los registros para cada proceso.
- SI hay más de una CPU, la CPU en la que se está ejecutando el proceso.
- VALOR DEL CONTADOR DE PROGRAMA, es decir la dirección de la próxima instrucción a ejecutar.
- Estadísticas del proceso.
- Datos del owner.
- Permisos del proceso.
- Signals aún no procesados.
Operaciones sobre procesos:
- Crear (un proceso)
- Destruir
- Suspender
- Reanudar
- Cambiar prioridad
- Bloquear
- Despertar
- Despachar
- Timeout
- Bloqueo
- Establecer una comunicación entre procesos
Al crear un proceso se lo da de alta en las estructura. Arranca con cero recursos.
Se va guardando la relación entre procesos padres e hijos. De esta forma por ejemplo, si un proceso termina por error, es probable que para evitar inconsistencias, se maten sus procesos hijos. Para no generar procesos huérfanos.
En los RCBs se guarda el id del recurso y determinadas características para su gestión.
Cuando un recurso le es dado a un proceso, esto se registra tanto en el PCB de uno, como en el RCB del otro.
Cuando un proceso pide un recurso y éste no está disponible, se va a bloquear. Esto se registra en los PCBs y RCBS correspondientes.
Diagrama de estados que modela el comportamiento de un SO multitarea:
Un ejemplo de estado suspendido son los modos degradados de los sistemas al haberse detectado una pieza rota del hardware.
Los estados de suspensión son estados para mejor control del sistema operativo. Consiste en suspender momentáneamente algunos procesos y luego reanudarlos. La reanudación es la operación inversa.
Diferencias entre suspensión y bloqueo: El bloqueo es una situación totalmente normal. Por qué bloqueamos ? Vamos a usar un recurso y está ocupado, lo tiene otro, o simplemente demora. El bloqueo pasa por algo que el propio proceso ejecutó.
La suspensión la decide el SO y utiliza esos estados para recordar en qué estado estaba antes de la suspensión.
Por qué suspendemos: Suspende el SO por diversas causas:
- Proceso que está dando un mal funcionamiento.
- Proceso asociado a un hardware roto.
- Alta carga del sistema.
Por ejemplo, ante el hardware roto, el sistema operativo detecta esa rotura y suspende los procesos críticos relacionados con esta circunstancia. Se pasa a un modo degradado.
Clasificaciones de procesos:
- Según su diseño: Reutilizables o Reentrantes.
- Según su acceso a los recursos (en particular CPU): Apropiativos o No apropiativos.
- Según su permanencia en memoria: Residentes o Swappeables (intercambiables).
- Según el nivel de privilegio: Privilegiados o No Privilegiados.
- Según su propietario: De usuario o Del sistema.
Provocan la creación de procesos:
- El arranque del sistema.
- Le ejecución desde un proceso, a través de la invocación a una llamada del sistema para la creación de procesos (fork).
- Una petición de usuario de crear un proceso.
- El inicio de un trabajo de proceso por lotes.
Creación de procesos en Unix:
Creación de procesos en Windows:
Eventos que provocan la terminación de procesos:
- Salida normal (voluntaria).
- Salida por error (voluntaria).
- Error fatal (involuntaria).
- Eliminado por otro proceso (involuntaria).
Se lleva el registro (tracking) de la creación de hijos sirve para matar consistentemente los hijos de un proceso que cayó o que hubo que matarlo.
Un ejemplo de estado suspendido son los modos degradados de los sistemas al haberse detectado una pieza rota del hardware.
El PCB guarda, para su proceso correspondiente, toda la información relevante.
Los diferentes PCBs se guardan en una estructura dinámica, típicamente una lista.
De todos modos la multitarea es gestionada por el scheduller, y controla todos los procesos que se ejecutan.
Sin embargo, por debajo de la misma, está toda la gestión de interrupciones.
Se apila el PC para recordar por dónde quedó.
Se va a ejecutar el handler de la interrupción.
Se salva el contexto.
Se establece el nuevo stack.
Se ejecuta el handler.
El shceduller decide qué proceso sigue.
Se regresa de atender la interrupción.
Se vuelve al mismo proceso que antes.
Cuando hay un deadlock, el uso de CPU baja? SI, porque al estar bloqueados no reciben CPU, de hecho ni siquiera participan del reparto.
Los procesos participantes de un deadlock, están bloqueados y no acaparan más recursos.
HILOS
Los hilos son un nivel de concurrencia complementario respecto al multitasking del sistema operativo.
Puede ser que el multitasking venga provisto por el SO, pero además el nivel de lenguaje de programación provea alguna forma de gestión de hilos.
Entonces tenemos procesos concurrentes y a su vez dentro de ellos hilos concurrentes.
Aquí conviene separar conceptos.
Por un lado tenemos que el SO maneja un conjunto de procesos (como parte de su multitasking) y a su vez se maneja un conjunto de hilos dentro de cada proceso (usualmente provistos por el lenguaje de programación).
Tanto los procesos como los hilos, pueden caer en deadlock. Un deadlock vamos a estudiar es un conjunto de procesos bloqueados entre ellos y es algo que merece la pena analizar en el marco del estudio de los SOs.
También la inanición, donde un proceso sin estar deadlock, sistemática y repetidamente le son negados determinados recursos.
Deadlock: un conjunto de procesos están en deadlock (o interbloqueo) cuando cada uno de ellos está en estado bloqueado, y lo está asociado a una causa que depende de otro proceso del conjunto.
Cada proceso espera por otro proceso del conjunto. Y así todos entre ellos, pero entonces están todos bloqueados.
Entonces ningún proceso participante del deadlock puede ejecutar.
Ningún recurso reservado por los procesos participantes del deadlock puede ser usado.
Multihilos
Ejemplo de tres hilos diferentes, colaborando en el marco de un proceso. Esto es un proceso de un programa procesador de textos con 3 hilos concurrentes:
Ejemplo: un servidor web con múltiples hilos.
Un proceso del web server, que contiene 3 hilos.
Modelo basado en multiproceso sin multihilo
En el modelo clásico tenemos un proceso por cada hilo, en el modelo eficiente, un proceso se divide en múltiples hilos.
Cada hilo tiene su contexto de ejecución, por ejemplo su propio stack:
Primitivas Posix de manejo de hilos:
Hay varias formas y varios detalles de implementación de los hilos.
Hilos en espacio de usuario:
En ese caso, la tabla de procesos está en el espacio de kernel del SO, y en el espacio de usuario están los procesos del mismo y sus hilos correspondientes.
Hilos en Kernel:
Otra forma de implementarlo, es cuando a nivel del kernel se maneja una tabla de procesos y una tabla de hilos.
Implementaciones híbridas:
Esta figura anterior, corresponde a una implementación mixta.
El scheduller de procesos debe lidiar con los procesos y los hilos.
Planificador y shceduller son lo mismo.
Se debe gestionar la actividad del planificador de procesos de modo de arbitrar procesos de usuario, procesos en kernel, etc de modo de optimizar su ejecución.
Multithreading
Multihilo refiere a la capacidad de un SO de soportar múltiples hilos de ejecución para un único proceso. En único tradicional de un solo hilo de ejecución por proceso, no se habla de hilos de ejecución sino de subprocesos.
En definitiva creamos un segundo nivel, donde los primero serían los procesos y el segundo serían los threads, y replicamos las condiciones.
Entonces tenemos n procesos y cada proceso tiene sus hilos, digamos en cantidad n_i
En definitiva los hilos son operacionalmente más cercanos entre sí que los procesos.
Gestión de interrupciones (drivers) VS gestión de procesos:
Lo primero es de más bajo nivel.
Cuando damos un movimiento en el mouse, se ejecutan miles de interrupciones.
Si para ejecutarlas se crearan miles de procesos, entonces esto sería muy ineficiente.
En lugar de ello se ejecutan a bajo nivel en el SO.
Tenemos entonces dos formas de organizar el cómputo en el SO.
Por un lado, procesos, que serían de alto nivel relativo.
Por otro interrupciones, y sus códigos handlers, que serían de bajo nivel relativo.
Ambos sistemas coexisten dentro del sistema operativo.
Podríamos decir que la capa más baja de SO la constituyen la gestión de interrupciones.
Por encima viene la gestión de procesos.
Funciones del núcleo del Sistema Operativo:
- Manejo de interrupciones
- Creación y destrucción de procesos
- Cambio de estados entre procesos
- Despacho
- Suspensión y reanudación
- Sincronización de procesos
- Comunicación entre procesos
- Gestión de PCB
- Apoyo a actividades de E/S
- Asignación y liberación de memoria
- Gestión del file system
- Mecanismos para llamada y retorno desde procedimientos
Tendencias… en cuanto al núcleo del sistema operativo.
En los sistemas informáticos tenemos hardware y software. Lo que se haga en el hardware debe estar más o menos estable a lo largo del tiempo, inmodificable, porque el hardware tiene como desventaja la dificultad de cambiarlo. Incluso si un software está en un firmware (en un chip como programa, por ejemplo las BIOS) es difícil de actualizar, de emparchar. Como ventaja, lo que hagamos en el hardware es más rápido y más seguro. El software es más maleable y en él va todo lo que evoluciona.
Cabe preguntarnos si el SO es hardware o software? Claramente, por su dinámica, es software, pero hay algunos movimientos del software al hardware.
El núcleo del SO le va pasando asuntos a la arquitectura, al hardware. Por qué? Porque la arquitectura ejecuta más rápido, más seguro.
Podemos pasar todo del SO a la arquitectura ? (En el ZX Spectrum (su SO), en el aire acondicionado, en los airbags del auto, el código está en un firmware, o sea, es todo hardware …)
El software es más maleable que el hardware. Es más fácil de modificar. Y nosotros emparchamos el SO a diario! Un SO actual ni soñar de tenerlo todo en el hardware.
PERO algunos asuntos pueden migrar a la arquitectura. Por ejemplo la controladora de disco y la controladora de red tienen asuntos que antes se resolvían en el nivel de SO y hoy están en el hardware. Ya que están incluidos en el firmware de algunos de los componentes.
Hay un nivel de gris entre la arquitectura y el SO.
Si el SO sigue pasando cosas para la arquitectura… se va a vaciar ? NOOOOO porque los niveles superiores le van pasando responsabilidades al sistema operativo.
Por ejemplo el multiusuario en red, en los 90’s estaba sobre el SO, hoy está dentro del SO. Es más seguro que estén dentro del SO y no en un aplicativo externo. Porque esto propicia brechas de seguridad.
Entonces, el SO no tiende a desaparecer, simplemente pasa algunos asuntos a la arquitectura y recibe otros asuntos de las capas superiores, en una dinámica bastante natural.
.png)
.png)
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.