Jerarquías de procesos
Los Sistemas Operativos deben disponer de una forma de crear y destruir procesos cuando se requiera durante la operación, teniendo además presente que los procesos pueden generar procesos hijos mediante llamadas al Sistema Operativo, pudiendo darse ejecución en paralelo. Respecto de los estados del proceso deben efectuarse las siguientes consideraciones:

• Cada proceso es una entidad independiente pero frecuentemente debe interactuar con otros procesos
• Los procesos pueden bloquearse en su ejecución porque:
  • Desde el punto de vista lógico no puede continuar porque espera datos que aún no están disponibles.
  • El Sistema Operativo asignó la cpu a otro proceso.
• Los estados que puede tener un proceso son:
  • En ejecución: utiliza la cpu en el instante dado.
  • Listo: ejecutable, se detiene en forma temporal para que se ejecute otro proceso.
  • Bloqueado: no se puede ejecutar debido a la ocurrencia de algún evento externo.
• Son posibles cuatro transiciones entre estos estados.

Modelo de dos estados.

El modelo de estados más simple es el de dos estados. En este modelo, un proceso puede estar ejecutándose o no. Cuando se crea un nuevo proceso, se pone en estado de No ejecución. En algún momento el proceso que se está ejecutando pasará al estado No ejecución y otro proceso se elegirá de la lista de procesos listos para ejecutar para ponerlo en estado Ejecución. De esta explicación se desprende que es necesario que el sistema operativo pueda seguirle la pista a los procesos, conociendo su estado y el lugar que ocupa en memoria. Además los procesos que no se están ejecutando deben guardarse en algún tipo de cola mientras esperan su turno para ejecutar.

Modelo de tres estados

Para poder manejar convenientemente una administración de procesador es necesario contar con un cierto juego de datos. Ese juego de datos será una tabla (BCP o en inglés PCB) en la cual se reflejará en qué estado se encuentra el proceso, por ejemplo, si está ejecutando o no. Los procesos, básicamente, se van a encontrar en este caso, en tres estados:
- Ejecutando.
- Listos para la ejecución.
- Bloqueados por alguna razón.

Sobre la base de estos estados se construye lo que se denomina Diagrama de Transición de Estado (DTE). Estar en la cola de Listos significa que el único recurso que a ese proceso le está haciendo falta es el recurso procesador. O sea, una vez seleccionado de esta cola pasa al estado de Ejecución. Se tiene una transición al estado de Bloqueados cada vez que el proceso pida algún recurso. Una vez que ese requerimiento ha sido satisfecho, el proceso pasará al estado de Listo porque ya no necesita otra cosa más que el recurso procesador.

Para manejar esa cola de Listos se requiere de una tabla, y esa tabla debe tener una identificación de los procesos (Ver figura).
Como los listos pueden ser muchos, hará falta un puntero al primero de esa cola de listos, y posiblemente un enganche entre los siguientes en el mismo estado. Esta tabla contiene los Bloques de Control de Procesos. En este caso se agrupan los BCP en una Tabla de Bloques de Control de Procesos (TBCP).

Modelo de cinco estados

El modelo anterior de dos estados funcionaría bien con una cola FIFO y planificación por turno rotatorio para los procesos que no están en ejecución, si los procesos estuvieran siempre listos para ejecutar. En la realidad, los procesos utilizan datos para operar con ellos, y puede suceder que no se encuentren listos, o que se deba esperar algún suceso antes de continuar, como una operación de Entrada/Salida. Es por esto que se necesita un estado donde los procesos permanezcan bloqueados esperando hasta que puedan proseguir. Se divide entonces al estado No ejecución en dos estados: Listo y Bloqueado. Se agregan además un estado Nuevo y otro Terminado.



Los cinco estados de este diagrama son los siguientes:

• Ejecución: el proceso está actualmente en ejecución.
• Listo: el proceso está listo para ser ejecutado, sólo está esperando que el planificador así lo disponga.
• Bloqueado: el proceso no puede ejecutar hasta que no se produzca cierto suceso, como una operación de Entrada/Salida.
• Nuevo: El proceso recién fue creado y todavía no fue admitido por el sistema operativo. En general los procesos que se encuentran en este estado todavía no fueron cargados en la memoria principal.
• Terminado: El proceso fue expulsado del grupo de procesos ejecutables, ya sea porque terminó o por algún fallo, como un error de protección, aritmético, etc.

Los nuevos estados Nuevo y Terminado son útiles para la de procesos. En este modelo los estados Bloqueado y Listo tienen ambos una cola de espera. Cuando un nuevo proceso es admitido por el sistema operativo, se sitúa en la cola de listos. A falta de un esquema de prioridades ésta puede ser una cola FIFO Los procesos suspendidos son mantenidos en una cola de bloqueados. Cuando se da un suceso se pasan a la cola de listos los procesos que esperaban por ese suceso. Si existe un esquema con diferentes niveles de prioridad de procesos es conveniente mantener varias colas de procesos listos, una para cada nivel de prioridad, lo que ayuda a determinar cuál es el proceso que más conviene ejecutar a continuación.


Durante su existencia un proceso pasa por una serie de estados discretos, siendo varias las circunstancias que pueden hacer que el mismo cambie de estado. Debido a ello se puede establecer una “Lista de Listos” para los procesos “listos” y una “Lista de Bloqueados” para los “bloqueados”. La “Lista de Listos” se mantiene en orden prioritario y la “Lista de Bloqueados” está desordenada, ya que los procesos se desbloquean en el orden en que tienen lugar los eventos que están esperando. Al admitirse un trabajo en el sistema se crea un proceso equivalente y es insertado en la última parte de la “Lista de Listos”. La asignación de la cpu al primer proceso de la “Lista de Listos” se denomina “Despacho”, que es ejecutado por una entidad del Sistema Operativo llamada “Despachador”. El “Bloqueo” es la única transición de estado iniciada por el propio proceso del usuario, puesto que las otras transiciones son iniciadas por entidades ajenas al proceso

Cuando el Sistema Operativo cambia la atención de la cpu entre los procesos, utiliza las áreas de preservación del PCB para mantener la información que necesita para reiniciar el proceso cuando consiga de nuevo la cpu. Los sistemas que administran los procesos deben poder crear, destruir, suspender, reanudar, cambiar la prioridad, bloquear, despertar y despachar un proceso. La “creación” de un proceso significa:

• Dar nombre al proceso.
• Insertar un proceso en la lista del sistema de procesos conocidos.
• Determinar la prioridad inicial del proceso.
• Crear el bloque de control del proceso.
• Asignar los recursos iniciales del proceso.

Un proceso puede “crear un nuevo proceso”, en cuyo caso el proceso creador se denomina “proceso padre” y el proceso creado “proceso hijo” y se obtiene una “estructura jerárquica de procesos”. La “destrucción” de un proceso implica:

• Borrarlo del sistema.
• Devolver sus recursos al sistema.
• Purgarlo de todas las listas o tablas del sistema.
• Borrar su bloque de control de procesos.

Los eventos que llevan a un proceso a cambiar de un estado a otro son:

1. Null --> New: El nuevo proceso es creado para ejecutar un programa.
2. New --> Ready: El S.O. realiza esta transición cuando está preparado para comenzar a ejecutarse.
3. Ready --> Running: El S.O. hace éste cambio de estado cuando es tiempo de elegir un nuevo proceso a ejecutar.
4. Running --> Exit: Este cambio de estado se produce cuando el proceso actualmente en ejecución es finalizado o abortado.
5. Running ---> Ready: Esta transición puede ocurrir cuando se ha alcanzado el límite máximo de tiempo de ejecución ininterrumpida (técnica encontrada comunmente en los S.O. con multiprogramación) o cuando, al trabajar con distintos niveles de prioridad, un proceso es reemplazado por otro de mayor prioridad.
6. Running --> Blocked: Esto ocurre cuando un proceso solicita algo por lo qu deba esperar. Este pedido es realizado, por lo general, en la forma de un system call (llamado de un programa en ejecución a un procedimiento que es parte del código del S.O.).
7. Blocked --> Ready: Este cambio tiene lugar al ocurrir el evento por el que estaba esperando un proceso.
8. Ready --> Exit: Esto ocurre cuando un proceso hijo es finalizado; ya sea por pedido del proceso padre o porque el padre en sí fue finalizado.
9. Blocked --> Exit: Idem ready --> exit.

Modelo de siete estados

Procesos suspendidosUna de las razones para implementar el estado Bloqueado era poder hacer que los procesos se puedan mantener esperando algún suceso, por ejemplo una Entrada/Salida. Sin embargo, al ser mucho más lentas estas operaciones, puede suceder en nuestro modelo de cinco estados que todos los procesos en memoria estén esperando en el estado Bloqueado y que no haya más memoria disponible para nuevos procesos. Podría conseguirse más memoria, aunque es probable que esto sólo permita procesos más grandes y no necesariamente nuevos procesos. Además hay un costo asociado a la memoria y de cualquier forma es probable que se llegaría al mismo estado con el tiempo. Otra solución es el intercambio. El intercambio se lleva a cabo moviendo una parte de un proceso o un proceso completo desde la memoria principal al disco, quedando en el estado Suspendido. Después del intercambio, se puede aceptar un nuevo proceso o traer a memoria un proceso suspendido anteriormente. El problema que se presenta ahora es que puede ser que si se decide traer a memoria un proceso que está en el estado Suspendido, el mismo todavía se encuentre bloqueado. Sólo convendría traerlo cuando ya está listo para ejecutar, esto implica que ya aconteció el suceso que estaba esperando cuando se bloqueó. Para tener esta diferenciación entre procesos suspendidos, ya sean listos como bloqueados, se utilizan cuatro estados: Listo, Bloqueado, Bloqueado y suspendido y Listo y suspendido.

-------------------------------------------------------------------


Llamadas al sistema operativo en UNIX

La comunicación del usuario con el sistema operativo Unix es a través de funciones llamadas "system calls" -SC- (llamadas al sistema). Por ejemplo una llamada al sistema para leer desde un archivo sería:

nro_bytes_leidos = read (fichero, buffer, nbytes);

La SC devuelve en nro_bytes_leidos los bytes que realmente ha leído. Este valor suele ser el mismo que nbytes, pero podría ser inferior si, por ejemplo, se hubiera alcanzado el fin del fichero durante la lectura.

Si la llamada no puede realizarse por algún error de algún tipo la función retornaría nro_bytes_leidos=-1 (un valor <0 es una condición de error en todas las llamdas) y el número de error de almacenaría en errno. Esta variable se puede visualizar mediante la función de tratamiento de error perror();

Una de las llamadas más importantes de un sistema Unix es la llamada fork(). El fork() es la llamada para crear procesos en Unix. Sun funcionalidad es similar a la planteada por Peterson (estudiada en SOpI) como instrucción Fork/Join pero aquí (en Unix no existe la primitiva Join) por lo cual los árboles de procesos son árboles abiertos y si se desean sincronizar procesos se deberán utilizar semáforos.

Cuando queremos crear un proceso hijo a partir de un proceso padre en el fichero del código fuente deberán estar el código de ambos, por ejemplo:

Instrucciones ....
n=fork();
if (n!0){
Aquí estarán las instrucciones de código del padre
} else{
Aquí estarán las intrucciones del código del hijo
}

Cuando la SC fork () se ejecuta el SO crea una réplica exacta del código en memoria del proceso original, que incluye los descriptores de ficheros, variables, datos y registros. Después del fork(), el proceso original (padre) y su réplica (hijo) continúan por separado. Justo después del fork todas las variables tienen igual valor para el padre y para el hijo, pero dado que están en diferente sitios en la memoria principal, cambios sobre estás no afectarán a la copia del otro y viceversa. La única variable diferente es el valor de la variable que retorna la SC fork() (n en nuestro ejemplo). Para el padre en valor de ésta es el PID del hijo (Process identificator) y para el hijo es igual a cero. Por ello es que luego del fork() cada proceso podrá seguir ejecutando un código diferente (a través del if-else en nuestro caso).
-----------------------------------