Del 08/04 al 12/04.
Procesos y Planificación del Procesador
1. Introducción:
Todas las
computadoras modernas hacen varias cosas al mismo tiempo. A la vez que ejecuta
un programa del usuario, una computadora puede leer de un disco e imprimir en
una terminal o impresora. En un sistema de multiprogramación, la CPU también
alterna de programa en programa, ejecutando cada uno de ellos por decenas o
cientos de milisegundos. Aunque, en sentido estricto, la CPU ejecuta en cierto
instante un solo programa, durante un segundo puede trabajar con varios de
ellos, lo que da una apariencia de paralelismo. A veces, las personas hablan de
seudo paralelismo para indicar este rápido intercambio de los programas en la
CPU, para distinguirlo del paralelismo real del hardware, donde se hacen
cálculos en la CPU a la vez que operan uno o más dispositivos de
entrada/salida. Es difícil mantener un registro de las distintas actividades
paralelas. Por lo tanto, los diseñadores del sistema operativo han desarrollado
con el tiempo un modelo que facilita el uso del paralelismo.
Objetivo
General:
·
Identificar los tipos de Implementación y modelos de
Procesos.
Objetivos
Específicos:
·
Determinar la diferencia entre procesos y threads.
·
Describir las operaciones sobre procesos y
sincronización.
·
Determinar la diferencia entre procesos e hilo.
1.1 Implementación del modelo de procesos.
Antes de describir la implementación del modelo
de procesos vamos a definir que es un proceso y modelos de procesos. Un proceso
es un programa en ejecución. Un proceso simple tiene
un hilo de ejecución, por el momento dejemos esta última definición como un concepto, luego se verá en más detalle el
concepto de hilo. Una vez definido que es un proceso nos podríamos preguntar
cuál es la diferencia entre un programa y un proceso, y básicamente la
diferencia es que un proceso es una actividad de cierto tipo que contiene un
programa, entradas salidas y estados.
Los procesos pueden ser cooperantes o
independientes, en el primer caso se entiende que los procesos interactúan
entre sí y pertenecen a una misma aplicación. En el caso de procesos
independientes en general se debe a que no interactúan y un proceso no requiere
información de otros o bien porque son procesos
que pertenecen a distintos usuarios.
Estados de los procesos
Un proceso puede estar en cualquiera de los
siguientes tres estados: Listo, En ejecución y Bloqueado.
Los procesos en el estado listo son los que
pueden pasar a estado de ejecución si el planificador los
selecciona. Los procesos en el estado ejecución son los que se están ejecutando
en el procesador en ese momento dado.
Los procesos que se encuentran en estado bloqueado están esperando la respuesta
de algún otro proceso para poder continuar con su ejecución. Por ejemplo
operación de E/S.
Diferencias entre hilos
y procesos
Primeramente en sistemas operativos, un hilo
de ejecución, hebra o subproceso es la unidad de
procesamiento más pequeña que puede ser planificada por un sistema operativo.
Los hilos se distinguen de los tradicionales
procesos en que los procesos son –generalmente– independientes, llevan bastante
información de estados, e interactúan sólo a través de mecanismos de comunicación dados por el sistema. Por otra parte, muchos hilos
generalmente comparten otros recursos de forma directa. En muchos de los sistemas operativos que dan
facilidades a los hilos, es más rápido cambiar de un hilo a otro dentro del
mismo proceso, que cambiar de un proceso a otro. Este fenómeno se debe a que
los hilos comparten datos y espacios de direcciones, mientras que los procesos,
al ser independientes, no lo hacen. Al cambiar de un proceso a otro el sistema
operativo (mediante el dispatcher)
genera lo que se conoce como overhead,
que es tiempo desperdiciado por el procesador para realizar un cambio de
contexto (context switch), en
este caso pasar del estado de ejecución (running)
al estado de espera (waiting) y
colocar el nuevo proceso en ejecución. En los hilos, como pertenecen a un mismo
proceso, al realizar un cambio de hilo el tiempo perdido es casi despreciable.
Sistemas operativos como Windows NT, OS/2 y Linux (2.5 o superiores) dicen tener hilos
"baratos", y procesos "costosos" mientras que en otros
sistemas no hay una gran diferencia.
Modelo de Procesos
Todo el
software ejecutable de la computadora, se organiza en varios procesos
secuenciales. Un proceso es tan solo un programa en ejecución, lo que incluye
los valores activos del contador, registros y variables del programa. Cada
proceso tiene su CPU virtual, la realidad es que la verdadera CPU alterna entre
los procesos, es mucho más fácil pensar en un conjunto de procesos en ejecución
paralela, que pensar que llevar un registro de la forma en que alterna la CPU
de programa en programa, esta alternativa se llama multiprogramación.
En UNIX,
los procesos se crean mediante la llamada los sistemas FORK, el cual crea una
copia idéntica del proceso que hace la llamada. Después de la llamada FORK, el
padre sigue su ejecución, en paralelo con el hijo. El padre puede dar lugar
entonces a más hijos, de forma que en cualquier momento podrían estar varis
hijos en ejecución. Los hijos también pueden ejecutar FORK, por lo que es
posible obtener un árbol de procesos, de profundidad arbitraria.
La implementación del modelo de procesos se
logra debido a que el sistema operativo almacena en una tabla denominada tabla
de control de procesos información relativa por cada proceso que se está
ejecutando en el procesador.Cada línea de esta tabla representa a un proceso. Una entrada contiene información importante acerca
del estado del proceso, incluyendo su contador de programa y su apuntador de
pila, asignación de memoria, archivos abiertos, Información de contabilidad y
planificación y todo lo que debe guardar cuando cambia del estado en ejecución a listo.
La información que se
almacena es la siguiente:
1)
Identificación del proceso.
2)
Identificación del proceso padre.
4)
Estado del procesador.
5)
Información de control de proceso
5.1)
Información del planificador.
1.2 Operaciones sobres Procesos y Planificación
Los
S.O. con multitarea permiten numerosas operaciones dedicadas a la gestión de
procesos. Entre ellas, las más importantes: creación, eliminación,
obtención de información, modificación, retardo y
activación.
Creación de procesos: crear (id_proceso, atributos);
El
S.O. primero comprobará que no existen errores en la llamada (por ejemplo,
comprueba que el procedimiento indicado no exista). A continuación se crea el
proceso, se pasan los atributos como parámetros, se reserva memoria para el
proceso (tanto para el BCP como para el código y los datos) y se añade a la
cola de preparado.
Eliminación de procesos: eliminar (id_proceso);
Para
eliminar un proceso es necesario que este sea hijo del proceso eliminador, ya
que de no ser así podría volverse inconsistente el sistema. Una vez realizada
la llamada, el S.O. verifica que no existen errores para a continuación liberar
los recursos retenidos por el proceso. Finalmente se destruye el BCP.
Obtención de información: inf_proc (id_proceso, est_BCP);
Devolverá
una copia del BCP del proceso requerido. El S.O. debe comprobar que no existen
errores en los parámetros.
Modificación de la información de un proceso: mod _inf (id_proceso, est_BCP);
El
proceso modificador debe enviar como
parámetros el PID del proceso que modifica y un nuevo BCP que sustituya al actual. El S.O. comprobará los
posibles errores producidos.
Retardar un proceso: retardar (tiempo);
El
proceso que realiza esta llamada se auto detiene durante el tiempo indicado y pierde el control
de la CPU durante ese tiempo. Los ciclos de reloj de espera se anotan en el BCP
(utilizados posteriormente en la planificación de procesos). Finalmente, cuando
el tiempo transcurre, el núcleo del S.O. introduce al proceso en la cola de
procesos preparados para intentar ejecutarlo inmediatamente.
Activar procesos retardados: activar (id_proceso);
Esta
función es privilegiada. El mecanismo para despertar procesos se activa en cada
ciclo de reloj, recorriéndose la cola de procesos retardados para activarlos o
disminuir en una unidad el número de pulsos de espera. Devuelve un código de
error si el PID que se pasa no existe.
La
comunicación entre procesos: necesaria si se desea que varios procesos puedan
colaborar para realizar una misma tarea. Sincronización es el funcionamiento
coordinado en la resolución de una tarea encomendada.
El
SO ofrece mecanismos básicos de comunicación, que permiten transferir cadenas
de bytes. Deben ser los procesos que se comunican quienes interpreten el
significado de las cadenas transferidas para su labor coordinada.
Los
mecanismos de comunicación y sincronización son dinámicos. Es decir, cuando se
necesita un mecanismo de este estilo, se crea, usa y destruye, de forma que no
se establezca de forma definitiva ningún mecanismo de comunicación, ya que
ellos podrían producir efectos indeseados. Es decir, la comunicación es algo
puntual.
a. crear: el proceso solicita la creación del mecanismo
b. enviar o escribir: el proceso emisor envía información al
proceso receptor
c. recibir o leer: el proceso receptor recibe información
d. destruir: el proceso solicita la destrucción del
mecanismo de comunicación
La comunicación puede ser síncrona y asíncrona:
a. síncrona: los dos procesos han de ejecutar servicios de
forma simultánea. El emisor ha de ejecutar el servicio enviar mientras el
receptor ejecuta recibir.
b. asíncrona: el emisor hace el envío y prosigue su
ejecución. El SO ofrece un almacenamiento intermedio
para guardar la información enviada, hasta que el receptor la solicite.
Ejemplo síncrono
La sección crítica
El problema de la sesión crítica consiste en
diseñar un protocolo que los procesos puedan usar para cooperar de esta forma.
Cualquier solución al problema de la sección
crítica deberá satisfacer los tres requisitos siguiente:
·
Exclusión mutua.- Si el proceso Pi está ejecutándose en su sección crítica, los demás
procesos no pueden estar ejecutando sus secciones críticas.
· Progreso.-
Si ningún proceso está ejecutando su sección crítica, y algunos procesos desean
entrar en sus correspondientes secciones críticas, sólo aquellos procesos que
no estén ejecutando sus secciones restantes pueden participar en la decisión de
cuál será el siguiente que entre en su sección crítica, y esta selección no se
puede posponer indefinidamente.
· Espera
limitada.- Existe un límite en el número de veces que se permite que otros
procesos entren en sus secciones críticas después de que un proceso haya hecho
una solicitud para entrar en su sección crítica y antes de que la misma haya
sido concedida.
Se usan dos métodos generales para gestionar
las secciones críticas en los sistemas operativos:
1. Kernels apropiativos.- Permite que un
proceso sea desalojado mientras se está ejecutando en modo kernel.
2. Kernels no apropiativos.- No
apropiativo no permite que un proceso que se esté ejecutando en modo kernel sea
desalojado.
1.3 Implementación
de threads
Hay dos grandes categorías en la
implementación de hilos:
·
Hilos a nivel de usuario
·
Hilos a nivel de Kernel
También conocidos como ULT (User Level Thread) y KLT (Kernel Level Thread)
Hilos a nivel de usuario
(ULT)
En una aplicación ULT pura, todo el trabajo de gestión de hilos lo realiza la aplicación y el
núcleo o kernel no es consciente de la existencia de hilos. Es posible
programar una aplicación como multihilo mediante una biblioteca de hilos. La
misma contiene el código para crear y destruir hilos, intercambiar
mensajes y datos entre hilos, para planificar la ejecución de hilos y para
salvar y restaurar el contexto de los hilos.
Todas las operaciones descritas se llevan a
cabo en el espacio de usuario de un mismo proceso. El kernel continua
planificando el proceso como una unidad y asignándole un único estado (Listo,
bloqueado, etc.).
Ventajas de los ULT
·
El intercambio de los hilos no necesita los
privilegios del modo kernel, porque todas las estructuras de datos están en el
espacio de direcciones de usuario de un mismo proceso. Por lo tanto, el proceso
no debe cambiar a modo kernel para gestionar hilos. Se evita la sobrecarga de
cambio de modo y con esto el sobrecoste u overhead.
·
Se puede realizar una planificación específica. Dependiendo
de qué aplicación sea, se puede decidir por una u otra planificación según sus
ventajas.
·
Los ULT pueden ejecutar en cualquier sistema
operativo. La biblioteca de hilos es un conjunto compartido.
Desventajas de los ULT
·
En la mayoría de los sistemas operativos las
llamadas al sistema (System calls) son bloqueantes. Cuando un hilo realiza una
llamada al sistema, se bloquea el mismo y también el resto de los hilos del
proceso.
·
En una estrategia ULT pura, una aplicación
multihilo no puede aprovechar las ventajas de los multiprocesadores. El núcleo
asigna un solo proceso a un solo procesador, ya que como el núcleo no
interviene, ve al conjunto de hilos como un solo proceso.
Una solución al bloqueo mediante a llamadas al
sistema es usando la técnica de jacketing, que es convertir una llamada
bloqueante en no bloqueante.
Hilos a nivel de núcleo
(KLT)
En una aplicación KLT pura, todo el trabajo de gestión de hilos lo realiza el kernel. En
el área de la aplicación no hay código de gestión de hilos, únicamente un API
(interfaz de programas de aplicación) para la gestión de hilos en el núcleo. Windows, Linux y OS/2 utilizan este método. Linux utiliza un método muy particular en
que no hace diferencia entre procesos e hilos, para Linux si varios procesos
creados con la llamada al sistema "clone" comparten el mismo espacio
de direcciones virtuales el sistema operativo la trata como hilos y lógicamente
son manejados por el kernel.
Ventajas de los KLT
·
El kernel puede planificar simultáneamente
múltiples hilos del mismo proceso en múltiples procesadores.
·
Si se bloquea un hilo, puede planificar otro
del mismo proceso.
·
Las propias funciones del kernel pueden ser
multihilo
Desventajas de los KLT
·
El paso de control de un hilo a otro precisa
de un cambio de modo.
Combinaciones ULT y KLT
La creación de hilos, así como la mayor parte
de la planificación y sincronización de los hilos de una aplicación se realiza
por completo en el espacio de usuario. Los múltiples ULT de una sola aplicación
se asocian con varios KLT. El programador puede ajustar el número de KLT para
cada aplicación y máquina para obtener el mejor resultado global.
ESTUDIANTES RESPONSABLES
- Apraez Torres Christian.
- España Rodas Karina.
- Lucas Marquez Abel.
- Mera Quiroz Junior.
- Quiñonez Angulo Francisco.
No hay comentarios:
Publicar un comentario