Gestión de Procesos en SO

La sección define un proceso como un programa en ejecución de forma secuencial. Se destaca la similitud entre los términos "job" y "proceso", aunque se enfatiza que un proceso es un programa en ejecución. Un componente esencial de un proceso es el contador de programa (PC), que indica la siguiente instrucción a ejecutar. El sistema operativo (SO) ejecuta varios programas, incluyendo sistemas batch (jobs) y sistemas de tiempo compartido (time-sharing), que gestionan programas o tareas de usuarios. Esta definición sienta las bases para comprender la gestión de procesos en los sistemas operativos, introduciendo conceptos fundamentales para el resto del capítulo. La comprensión de esta definición inicial es crucial para entender los estados, la planificación y la comunicación entre procesos.

Un proceso atraviesa diferentes estados durante su ciclo de vida. El documento menciona explícitamente dos estados: new (se está creando) y running (en ejecución). Se infiere la existencia de otros estados implícitamente, ya que se habla de cambios de estado a lo largo de la vida del proceso. Esta transición entre estados es fundamental para la gestión de procesos, permitiendo al sistema operativo administrar eficientemente los recursos. La descripción de los estados es una parte esencial para entender la dinámica de un proceso y su interacción con el sistema operativo, preparando el terreno para comprender la gestión de colas y la planificación de procesos.

El PCB es una estructura de datos fundamental que contiene información crucial asociada a cada proceso. Esta información incluye el estado actual del proceso, el valor del contador de programa (PC), los registros de la CPU, información relevante para la planificación de la CPU (CPU scheduling) e información para la gestión de memoria (Memory-management). El PCB es esencial para el correcto funcionamiento del sistema operativo, ya que permite al SO realizar un seguimiento del estado de cada proceso y gestionar su ejecución de manera eficiente. La información contenida en el PCB es vital para el cambio de contexto, la planificación y la administración de los recursos del sistema operativo.

Se describen dos colas importantes en la gestión de procesos: la job queue (cola de trabajos), que contiene todos los procesos del sistema, y la ready queue (cola de listos), que contiene los procesos residentes en memoria principal, listos para su ejecución. Estas colas son elementos clave en la administración de la ejecución de procesos, permitiendo al sistema operativo organizar y priorizar la ejecución de los procesos. La comprensión de estas colas es esencial para comprender los algoritmos de planificación y la gestión general de procesos dentro del sistema operativo.

El texto describe dos tipos de despachadores: el despachador a largo plazo (long-term scheduler o job scheduler) y el despachador a corto plazo (short-term scheduler). El primero selecciona qué procesos se añaden a la cola de listos (ready queue) desde la job queue, controlando el grado de multiprogramación. El segundo, en cambio, se invoca con mucha más frecuencia (milisegundos) y debe ser rápido, seleccionando qué proceso en la cola de listos se ejecutará en la CPU. Se destaca la diferencia en la frecuencia de invocación y, por ende, en los requisitos de velocidad de cada uno. La comprensión de estos dos despachadores es esencial para entender cómo se gestiona la ejecución de procesos en un sistema operativo multitarea.

Dentro de la planificación, se introduce la clasificación de procesos en función de su comportamiento. Se mencionan los procesos I/O-bound, que dedican más tiempo a las operaciones de entrada/salida (I/O) que al cómputo, realizando ráfagas cortas de procesamiento en la CPU. Esta distinción es crucial para los algoritmos de planificación, ya que los procesos I/O-bound pueden liberar la CPU con frecuencia, permitiendo un mejor aprovechamiento de los recursos. La clasificación de procesos impacta directamente en la eficiencia de la planificación y la optimización del uso de la CPU.

El cambio de contexto (context switch) se describe como el proceso de guardar el estado de un proceso y cargar el estado de otro cuando la CPU cambia de tarea. Este proceso implica guardar información del PCB, incluyendo el valor del contador de programa (PC) y los registros de la CPU. El cambio de contexto es un elemento clave en la multitarea, permitiendo al sistema operativo alternar entre diferentes procesos y dar la impresión de que se ejecutan simultáneamente. La eficiencia del cambio de contexto es un factor crítico para el rendimiento del sistema operativo.

La creación de procesos se describe como un proceso jerárquico donde los procesos padres crean procesos hijos, que a su vez pueden crear otros, formando un árbol de procesos. Los procesos comparten recursos; los padres comparten todos sus recursos, mientras que los hijos heredan un subconjunto. En cuanto al espacio de direcciones, el hijo duplica el del padre, pero ejecuta su propio programa. Se menciona como ejemplo la llamada al sistema fork() en sistemas UNIX, que crea un nuevo proceso. El fragmento de código en C que muestra la función fork() ilustra la creación de un proceso hijo desde un proceso padre, enfatizando la importancia de la gestión adecuada de los recursos compartidos entre ellos.

Un proceso finaliza su ejecución cuando ejecuta su última instrucción y solicita al sistema operativo que lo elimine mediante la llamada exit(). También se menciona la posibilidad de que el proceso padre termine la ejecución de un proceso hijo mediante abort(), especialmente si el hijo excede los recursos asignados. El proceso padre puede recibir datos del hijo a través de wait(). Una vez finalizado, el sistema operativo libera los recursos asignados al proceso. El proceso de terminación es esencial para liberar recursos del sistema y evitar fugas de memoria u otros problemas. El uso correcto de exit() y wait() garantiza la gestión eficiente de la finalización de los procesos.

La sección contrasta procesos independientes (que no se afectan mutuamente) con procesos en cooperación (que sí interactúan). Se destacan las ventajas de la cooperación: compartir información, acelerar la ejecución (speed-up) y modularidad. El texto introduce el problema productor-consumidor como un paradigma de procesos cooperantes, donde un productor genera información utilizada por un consumidor. Esta introducción a los procesos cooperantes y sus ventajas establece la necesidad de mecanismos de comunicación interprocesos para la sincronización y el intercambio eficiente de datos entre procesos.

La comunicación interprocesos (IPC) se presenta como un mecanismo para comunicar y sincronizar acciones entre procesos. Se menciona el sistema de mensajes como un método donde los procesos se comunican sin usar variables compartidas. Las operaciones básicas de IPC son send(message) y receive(message), con mensajes de tamaño fijo o variable. Para la comunicación, los procesos necesitan establecer un canal y luego intercambiar mensajes. Se plantea la necesidad de una implementación física del canal, como memoria compartida o el bus del sistema, con preguntas sobre los detalles de implementación, como el establecimiento de canales, la capacidad de un canal y el tamaño de los mensajes.

Se distinguen dos tipos de comunicación: directa e indirecta. En la comunicación directa, los procesos se refieren explícitamente entre sí mediante send(P, message) y receive(Q, message). Los canales se establecen automáticamente y se asocian a un único par de procesos. La comunicación indirecta, en cambio, utiliza buzones (mailboxes) con identificadores únicos. Los procesos se comunican si comparten un buzón. Un canal puede asociarse con múltiples procesos, permitiendo mayor flexibilidad en la comunicación. Se discute el problema de los buzones compartidos y cómo resolver el conflicto de acceso concurrente a un buzón por múltiples procesos.

Se abordan aspectos de sincronización, incluyendo el envío de mensajes con bloqueo (blocking) y sin bloqueo (non-blocking). El envío con bloqueo (blocking send) bloquea al remitente hasta que el mensaje es recibido, mientras que el envío sin bloqueo no. El receptor también puede ser bloqueado (blocking receive) hasta que llegue un mensaje. El concepto de buffering implica asociar una cola de mensajes al canal, con diferentes implementaciones como la cola de capacidad cero (0 mensajes). Estas técnicas de sincronización y buffering son esenciales para evitar condiciones de carrera y asegurar la comunicación confiable entre procesos cooperantes.

Finalmente, se introducen las técnicas de comunicación cliente-servidor utilizando sockets y llamadas a procedimientos remotos (RPC). Un socket se define como un punto terminal de comunicación, formado por una dirección IP y un puerto. Se ilustra con el ejemplo de un socket 161.25.19.8:1625. Las RPC abstraen las llamadas a procedimientos entre procesos en sistemas en red, utilizando stubs como proxies en el cliente. Se menciona la invocación de métodos remotos (RMI) como un mecanismo similar a las RPC.

Se define un socket como un punto terminal de comunicación, que resulta de la concatenación de una dirección IP y un puerto. Se proporciona un ejemplo: el socket 161.25.19.8:1625 hace referencia al puerto 1625 del host 161.25.19.8. Los sockets son un componente fundamental para la comunicación cliente-servidor en redes, permitiendo a los procesos establecer conexiones y enviar/recibir datos. Esta definición de socket introduce un mecanismo concreto para la comunicación entre procesos en un entorno de red.

Las llamadas a procedimientos remotos (RPC) se presentan como un mecanismo que abstrae las llamadas a procedimientos entre procesos en sistemas en red. Se mencionan los stubs, que actúan como proxies en el cliente para el procedimiento en el servidor. Las RPC simplifican la comunicación al permitir que un proceso cliente llame a un procedimiento en un servidor de forma transparente, ocultando la complejidad de la comunicación subyacente en la red. Este mecanismo facilita el desarrollo de aplicaciones distribuidas.

Por último, se menciona la invocación de métodos remotos (RMI) como un mecanismo similar a las RPC. Si bien no se detalla, se deja claro que comparte la funcionalidad de permitir la invocación de métodos en un servidor remoto desde un cliente de forma transparente, similar a lo que hacen las RPC.