Gestión de Procesos: Apuntes de Sistemas Operativos FIB

Y 0 flashcards y 6 preguntas más en el documento.

Texto del documento

APUNTES SISTEMAS OPERATIVOS Grado en Ingeniería Informática Universidad Politécnica de Cataluña AprenAI 2026-2027 Apuntes y resumen de Gestión de Procesos para Sistemas Operativos de la FIB (UPC): ciclo de vida, PCB, fork y exec, señales POSIX, Round Robin y CFS.

APREN.AI Índice 1 Concepto de Proceso, PCB y Hilos de Ejecución Definición de proceso y recursos necesarios Bloque de Control de Proceso (PCB) Objetivos del multiprocesamiento: concurrencia y paralelismo Hilos de ejecución (Threads) Modelos de hilos y balance de rendimiento 2 Estados del Proceso y Propiedades en Linux El ciclo de vida del proceso: estados y transiciones Agrupación de propiedades de un proceso en Linux Servicios del sistema operativo para procesos 3 Ciclo de Vida del Proceso: fork, exec, exit y waitpid Creación de procesos y jerarquía con fork Reglas de herencia tras la invocación de fork Terminación con exit y sincronización con waitpid Mutación del ejecutable mediante la familia exec 4 Comunicación entre Procesos y Manejo de Señales POSIX Modelos de comunicación entre procesos (IPC) Señales POSIX: naturaleza y ciclo de vida Estructuras del PCB y manipulación de máscaras Instalación de manejadores con sigaction y envío de señales Sincronización y espera: espera activa frente a sigsuspend Herencia de señales en fork y exec 5 Planificación de Procesos, Cambio de Contexto y Gestión del Kernel Estructuras del kernel para la gestión de procesos El planificador y las políticas de asignación Mecanismo de cambio de contexto (context switch) Métricas de rendimiento y algoritmos de planificación Impacto interno de las llamadas al sistema en las estructuras del kernel 6 Protección y Seguridad en el Sistema Operativo Protección frente a seguridad Control de acceso e identidad en el sistema Privilegios especiales: el usuario root y el mecanismo setuid Los cuatro niveles de seguridad 7 Resumen para repasar Gestión de Procesos: Apuntes de Sistemas Operativos FIB 1 Estructuras y Conceptos Básicos Estados y Ciclo de Vida del Proceso Señales POSIX e IPC Planificación de CPU Protección y Seguridad Soluciones de las preguntas de repaso Estos apuntes pueden contener errores u omisiones.

Son un material de apoyo y no sustituyen al temario oficial ni al profesorado: contrasta la información importante. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 2 1 Concepto de Proceso, PCB y Hilos de Ejecución AL ACABAR SABRÁS Distinguir con precisión un programa ejecutable de un proceso activo en memoria. Desglosar los componentes hardware y software integrados en el Bloque de Control de Proceso (PCB). Diferenciar los conceptos y métricas de concurrencia y paralelismo en arquitecturas mono y multinúcleo. Identificar los elementos privados frente a los compartidos en la arquitectura de un hilo de ejecución.

PIÉNSALO ANTES DE LEER 1 ¿Por qué un procesador de un solo núcleo puede reproducir música y responder al teclado al mismo tiempo sin trabarse? Un sistema operativo moderno gestiona múltiples tareas de forma eficiente mediante abstracciones fundamentales sobre el hardware. La base de esta gestión reside en la distinción entre el código pasivo almacenado en disco y la entidad activa que consume cómputo y memoria. ESQUEMA Estructura del tema Gestión de Procesos Definición de proceso y recursos necesarios Un proceso es la representación que tiene el SO de un programa en ejecución.

Mientras que un ejecutable es un archivo estático que contiene instrucciones y definiciones de datos, el proceso constituye una entidad dinámica que requiere recursos asignados para poder ejecutarse: Fundamentos y Abstracciones Concepto de proceso, PCB e hilos Ciclo y Estados Transiciones en Linux y llamadas del ciclo de vida Coordinación y Planificación Señales POSIX, IPC y algoritmos de CPU Seguridad Mecanismos de protección y credenciales Gestión de Procesos: Apuntes de Sistemas Operativos FIB 3 Espacio de direcciones: memoria asignada que alberga las secciones de código, datos globales y la pila (stack).

Contexto de CPU: estado inicializado de los registros de hardware y punteros necesarios para computar. Acceso a dispositivos: periféricos y canales de comunicación cuya interacción requiere privilegios en modo núcleo (kernel). Cada lanzamiento de un ejecutable genera una nueva entidad activa supervisada por el núcleo mediante estructuras internas específicas. Esquema del flujo de creación y gestión de un proceso en el núcleo. Bloque de Control de Proceso (PCB) Para administrar cada proceso activo, el sistema operativo utiliza una estructura de datos denominada Bloque de Control de Proceso o PCB (Process Control Block).

La información del PCB varía según el sistema y la arquitectura hardware subyacente, agrupándose en tres bloques fundamentales: Categoría Componentes almacenados Función en el sistema Espacio de direcciones Descripción de regiones de memoria: código (texto), datos y pila. Delimita las zonas de memoria que pertenecen al proceso. Contexto de ejecución SW Identificador de proceso (PID), métricas para la planificación de CPU, estadísticas y uso de dispositivos. Permite al planificador gestionar la prioridad y vigilar el consumo de recursos (véase «Estados del Proceso y Propiedades en Linux»).

Contexto de ejecución HW Tablas de páginas para traducción de memoria virtual, contador de programa (Program Counter) y registros de CPU. Guarda el estado físico de cómputo para restaurarlo al reanudar la ejecución. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 4 Gracias a esta estructura, el sistema operativo puede suspender la actividad de un proceso, ceder el procesador a otro y retomar el primero en idéntico punto sin pérdida de información (véase «Planificación de Procesos, Cambio de Contexto y Gestión del Kernel»). COMPRUEBA 2 ¿Por qué se separa el contexto hardware del contexto software dentro del PCB?

Objetivos del multiprocesamiento: concurrencia y paralelismo Los sistemas multiprogramados ejecutan múltiples procesos simultáneamente con dos metas primordiales: explotar el paralelismo real sobre arquitecturas con varios núcleos y aprovechar los tiempos muertos de entrada/salida (E/S). Cuando una tarea espera datos de un dispositivo lento (como disco o red), la CPU se asigna a otro proceso preparado, produciendo la ilusión de disponer de más procesadores físicos de los reales. DEFINICIÓN La concurrencia es la capacidad del sistema para hacer avanzar múltiples tareas en un mismo intervalo temporal compartiendo recursos.

El paralelismo ocurre cuando dos o más flujos se ejecutan de forma estrictamente simultánea en el mismo instante sobre núcleos físicos distintos. El grado de concurrencia representa el número de procesos que se encuentran activos e intercalados temporalmente, mientras que el grado de paralelismo cuantifica los procesos que la arquitectura ejecuta de manera físicamente simultánea. Según el orden de su flujo temporal, los procesos se dividen en: Concurrentes: pueden intercalarse o progresar en paralelo si la arquitectura dispone de hardware suficiente.

Secuenciales: se ejecutan necesariamente uno tras otro de forma obligada por el programador mediante mecanismos de sincronización, tales como señales o la espera de finalización (véase «Ciclo de Vida del Proceso: fork, exec, exit y waitpid» y «Comunicación entre Procesos y Manejo de Señales POSIX»). COMPRUEBA 3 ¿Puede existir concurrencia sin paralelismo en un sistema informático? Hilos de ejecución (Threads) Un proceso funciona como la unidad de asignación y protección de recursos (memoria, descriptores y periféricos). Dentro de él, un hilo de ejecución (thread) constituye la unidad mínima de asignación de tiempo de CPU para la planificación.

Cada fragmento de código con capacidad de cómputo autónomo se asocia a un hilo. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 5 ESQUEMA Distribución de recursos en un proceso multihilo Al instanciarse un proceso, nace con un hilo inicial y puede generar más flujos durante su ciclo de vida. Los hilos comparten todos los recursos del proceso (el espacio de memoria global y las tablas de archivos), pero cada uno retiene de manera privada su propio contexto de ejecución: Identificador de hilo (TID, Thread ID). Puntero a pila (Stack Pointer) para gestionar llamadas a función y variables locales. Contador de programa (Program Counter) con la dirección de la siguiente instrucción.

Conjunto de registros de CPU (Register File). Variable de control de errores (errno). Modelos de hilos y balance de rendimiento Los hilos permiten descomponer aplicaciones en tareas modulares, responder con eficiencia a peticiones de entrada/salida y canalizar solicitudes concurrentes en cascada para preservar la calidad de servicio. Su gestión puede implementarse a nivel de usuario (User Level Threads) o a nivel de núcleo (Kernel Level Threads), con diferentes compensaciones operativas. Aspecto Hilos de ejecución Procesos independientes Coste de gestión Menor sobrecarga al crear, terminar y cambiar de contexto dentro del mismo proceso.

Mayor coste en tiempo y recursos al gestionar espacios y tablas separadas. Comunicación Directa mediante memoria compartida del proceso sin llamadas al sistema. Requiere mecanismos explícitos de comunicación entre procesos (IPC). Programación Mayor complejidad por problemas de sincronización y exclusión mutua. Aislamiento completo de memoria que reduce interferencias accidentales.

Recursos compartidos del proceso Comunes a todos los hilos Espacio de memoria Código, datos globales y montículo Entrada y Salida Archivos abiertos y dispositivos Contexto privado del hilo Específico de cada flujo Registros y PC Estado de ejecución actual Pila (Stack Pointer) Variables locales y retornos Identidad y estado TID y variable errno Gestión de Procesos: Apuntes de Sistemas Operativos FIB 6 ERROR FRECUENTE Un error común en exámenes es asumir que los hilos tienen pilas compartidas o que no comparten memoria de datos.

Cada hilo cuenta obligatoriamente con su propio puntero de pila (Stack Pointer) y registros para no sobreescribir sus llamadas a funciones, pero comparte el espacio de datos globales. Esta memoria compartida elimina la necesidad de llamadas al sistema para transferir información, pero introduce fallos graves de sincronización y exclusión mutua (carreras críticas, inconsistencia de variables y bloqueos mutuos) si no se programa con cuidado. COMPRUEBA 4 ¿Qué elementos del contexto de cómputo NO se comparten entre los diferentes hilos de un mismo proceso?

IDEAS CLAVE Un proceso representa la abstracción del sistema operativo para un programa en ejecución con espacio de direcciones, contexto de CPU y acceso a dispositivos. El PCB reúne la memoria asignada, el contexto hardware (registros, contador de programa, tablas de páginas) y el contexto software (PID, métricas de planificación y estadísticas). La concurrencia intercala el avance de múltiples tareas en el tiempo, mientras que el paralelismo exige hardware con múltiples núcleos para ejecutarlas en el mismo instante.

El hilo es la unidad mínima de planificación de CPU; comparte los recursos y la memoria del proceso padre, pero preserva su propio TID, Stack Pointer, Program Counter, registros y errno. La memoria compartida entre hilos agiliza la comunicación sin llamadas al sistema, pero acarrea riesgos de sincronización y exclusión mutua. COMPRUEBA LO QUE HAS APRENDIDO 5. ¿Cuál es la diferencia principal entre un programa ejecutable y un proceso? 6. ¿Qué consecuencias tiene compartir el espacio de memoria entre varios hilos de un mismo proceso? 7. ¿Qué dos objetivos persigue el multiprocesamiento al gestionar la CPU? Test Rodea la respuesta correcta. Las soluciones están al final. 8.

¿Qué elemento forma parte del contexto exclusivo de un hilo y no se comparte con los demás? Tabla de páginas a) Descriptores de dispositivos b) Espacio de direcciones c) Contador de programa (PC) d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 7 9. ¿En qué se diferencia el paralelismo de la concurrencia? 10. ¿Cuál es la principal ventaja de los hilos frente a la creación de procesos independientes? 11. ¿Qué bloque del PCB contiene la información de métricas para el planificador y el PID? 2 Estados del Proceso y Propiedades en Linux AL ACABAR SABRÁS Identificar los estados del ciclo de vida de un proceso y las causas de sus transiciones.

Relacionar la multiprogramación y la E/S bloqueante con la topología del grafo de estados. Distinguir las tres categorías de propiedades de un proceso en sistemas Linux: identidad, entorno y contexto. PIÉNSALO ANTES DE LEER 12 ¿Por qué un sistema operativo no puede limitarse a alternar únicamente entre los estados de ejecución y espera de CPU? Un proceso no permanece usando la CPU de forma ininterrumpida durante toda su existencia. A menudo debe aguardar respuestas de periféricos o sincronizarse con otras tareas. Para maximizar el rendimiento del hardware, los sistemas operativos multiprogramados clasifican la actividad de cada tarea mediante un autómata de estados.

El ciclo de vida del proceso: estados y transiciones El núcleo rastrea la condición en que se encuentra cada tarea activa mediante un campo específico dentro de su Process Control Block (PCB) (véase «Concepto de Proceso, PCB y Hilos de Ejecución») o manteniéndola en colas separadas según su situación operativa.

El comportamiento dinámico se modela con un grafo de transiciones entre cuatro estados fundamentales: Requiere siempre sincronización mediante señales a) Ejecuta procesos estrictamente en el mismo instante b) Solo puede implementarse a nivel de usuario c) Impide el uso de memoria compartida d) Menor coste de creación y cambio de contexto a) Eliminación completa de la pila de llamadas b) Inmunidad frente a fallos de sincronización c) Aislamiento total del espacio de memoria d) Espacio de direcciones a) Contexto de ejecución software b) Puntero de pila de usuario c) Contexto de ejecución hardware d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 8 RUN: el proceso posee una CPU asignada y sus instrucciones se están ejecutando en el procesador en ese instante.

READY: el proceso está listo para ejecutarse y dispone de todos los recursos necesarios, pero se encuentra a la espera de que el sistema le asigne tiempo de procesador. BLOCKED: el proceso no consume procesador porque aguarda la resolución de una operación de entrada/salida (como teclado, disco o red) o la recepción de un evento o señal externa. ZOMBIE: el proceso ha concluido su ejecución pero su estructura básica aún no ha sido eliminada de las tablas del núcleo. Las características de diseño del sistema operativo condicionan directamente la existencia de estos estados.

La presencia simultánea de READY y RUN surge debido a la multiprogramación, donde varios procesos compiten por los procesadores disponibles. Por su parte, el estado BLOCKED existe porque el sistema admite llamadas al sistema con entrada/salida bloqueante. Diagrama de estados y transiciones fundamentales del ciclo de vida de un proceso. El paso entre estos estados ocurre siguiendo eventos bien definidos: Creación a READY: al crearse mediante la llamada fork (véase «Ciclo de Vida del Proceso: fork, exec, exit y waitpid»), el nuevo proceso pasa a la cola de listos. 1 READY a RUN: el planificador del sistema operativo selecciona el proceso y le otorga el control de la CPU.

2 RUN a READY: se produce cuando se agota la cuota temporal de procesador asignada a esa tarea. 3 RUN a BLOCKED: la tarea solicita una operación de entrada/salida bloqueante (como operaciones de lectura o escritura) o invoca primitivas de espera activa de eventos (como sigsuspend ; véase «Comunicación entre Procesos y Manejo de Señales POSIX»). 4 BLOCKED a READY: cuando el dispositivo completa la transferencia de datos o se entrega la señal esperada, el proceso vuelve a competir por CPU. 5 RUN a ZOMBIE: el proceso finaliza su código ejecutando exit (véase «Ciclo de Vida del Proceso: fork, exec, exit y waitpid») y queda a la espera de que su progenitor consulte su estado final.

6 Gestión de Procesos: Apuntes de Sistemas Operativos FIB 9 COMPRUEBA 13 ¿Por qué un proceso desbloqueado tras completar una lectura de disco pasa a READY y no directamente a RUN? ERROR FRECUENTE Un error común en exámenes es asumir que un proceso en estado ZOMBIE consume tiempo de procesador o memoria de usuario. Un proceso difunto ya no ejecuta instrucciones ni retiene memoria asignada; un proceso zombie únicamente conserva su entrada en la tabla de procesos del núcleo hasta que su padre invoca wait() o waitpid() para recoger el código de terminación.

Agrupación de propiedades de un proceso en Linux En Linux, la información necesaria para gestionar y diferenciar la ejecución de cada programa se almacena íntegramente en el núcleo y se estructura en tres categorías principales: Grupo de propiedades Elementos constitutivos Propósito principal Identidad PID, identificadores de usuario (UID) y de grupo (GID). Determinar quién es el proceso y a qué recursos del sistema tiene derecho de acceso. Entorno Vector de argumentos ( argv en C) y variables de entorno (como HOME , PATH o USERNAME ). Configurar el contexto de ejecución, rutas de búsqueda y parámetros de inicio del programa.

Contexto Espacio de direcciones, registros y recursos utilizados durante la ejecución. Registrar la información dinámica y los recursos del sistema en uso a lo largo del tiempo. La identidad del proceso fija sus privilegios frente al resto del sistema. El Process ID (PID) es un valor numérico único asignado por el núcleo a cada tarea al nacer. Este identificador se utiliza en llamadas al sistema para enviar eventos, señales o alterar sus parámetros de ejecución.

A su vez, las credenciales asocian el proceso a un usuario concreto (UID) y a uno o más grupos (GID), delimitando de manera estricta los permisos de lectura, modificación y ejecución sobre archivos y periféricos (véase «Protección y Seguridad en el Sistema Operativo»). PARA RECORDARLO Para clasificar las propiedades de un proceso en Linux, piensa en una persona: la identidad es su DNI y sus permisos de acceso; el entorno es su maleta y herramientas que trae de casa; el contexto es la postura y los apuntes abiertos sobre su mesa en un instante dado.

Gestión de Procesos: Apuntes de Sistemas Operativos FIB 10 Servicios del sistema operativo para procesos Para controlar la actividad concurrente, el sistema operativo proporciona a los programas un conjunto de interfaces mediante llamadas al sistema organizadas en cuatro áreas funcionales: Gestión del ciclo de vida: servicios para la creación, planificación y terminación de tareas. Control de ejecución: funciones para bloquear y desbloquear procesos frente a condiciones de espera. Sincronización: mecanismos destinados a ordenar temporalmente las actividades y evitar colisiones entre procesos cooperativos.

Comunicación: herramientas para el intercambio de datos, destacando esquemas de memoria compartida, dispositivos especiales y gestión de señales. ESQUEMA Propiedades de un Proceso en Linux COMPRUEBA 14 ¿Qué componente del sistema operativo determina si un proceso tiene permiso para modificar un archivo concreto en disco?

Identidad Quién es y sus permisos de acceso PID Identificador numérico único Credenciales UID y GID para control de acceso Entorno Parámetros y configuración recibida Argumentos argv Parámetros pasados al programa Variables de entorno Variables HOME, PATH, USERNAME Contexto Estado dinámico y recursos en uso Gestión de Procesos: Apuntes de Sistemas Operativos FIB 11 IDEAS CLAVE Los estados esenciales de un proceso en sistemas multiprogramados son RUN, READY, BLOCKED y ZOMBIE. La necesidad del estado BLOCKED proviene de la existencia de operaciones de entrada/salida bloqueantes.

Un proceso en estado ZOMBIE ya ha terminado pero retiene su entrada en las estructuras del núcleo hasta que su padre lea su salida. Las propiedades de un proceso en Linux se dividen en identidad (PID, UID, GID), entorno (argv, variables de entorno) y contexto. El sistema operativo suministra llamadas al sistema para gestionar el ciclo de vida, bloquear/desbloquear, sincronizar y comunicar procesos. COMPRUEBA LO QUE HAS APRENDIDO 15. ¿Qué suceso causa la transición de un proceso desde el estado BLOCKED hasta el estado READY? 16. ¿Qué tres categorías forman las propiedades de un proceso bajo Linux y qué abarca la identidad? Test Rodea la respuesta correcta. Las soluciones están al final. 17.

¿Qué estado corresponde a un proceso listo para correr pero a la espera de asignación de CPU? 18. ¿Por qué un proceso pasa de RUN al estado BLOCKED? 19. ¿Qué retiene un proceso en estado ZOMBIE dentro del sistema operativo? BLOCKED a) ZOMBIE b) RUN c) READY d) Por finalizar su ejecución mediante exit a) Por ser seleccionado por el planificador b) Por solicitar una E/S bloqueante o esperar eventos c) Por agotarse su cuota de procesador d) Su entrada y datos de terminación en el PCB a) Asignación activa de ciclos de procesador b) Todo su espacio de memoria en RAM c) Todos sus descriptores de ficheros abiertos d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 12 20.

¿Qué elemento forma parte del entorno de un proceso en Linux? 3 Ciclo de Vida del Proceso: fork, exec, exit y waitpid AL ACABAR SABRÁS Diferenciar los valores de retorno de fork() para estructurar el flujo de ejecución entre padre e hijo. Identificar los atributos del proceso que se heredan y los que se reinician tras invocar fork(). Explicar el ciclo de recolección de procesos con exit y waitpid para prevenir estados zombie. Describir la mutación del espacio de direcciones mediante las funciones de la familia exec. PIÉNSALO ANTES DE LEER 21 ¿Por qué un proceso hijo empieza a trabajar directamente en la línea siguiente a fork() en vez de reiniciar desde el principio del programa?

Creación de procesos y jerarquía con fork En los sistemas UNIX y Linux, la creación de nuevos flujos de computación sigue un modelo estrictamente jerárquico. Salvo el proceso inicial del sistema (el proceso init o systemd), todo proceso en ejecución nace a partir de otro proceso preexistente mediante la llamada al sistema fork() . Esta relación estructural se denomina relación padre-hijo y organiza los procesos en una estructura en forma de árbol. Cuando un proceso invoca a fork() , el núcleo del sistema operativo crea una entidad independiente que constituye un duplicado casi exacto del llamador.

En este instante, el sistema operativo debe resolver aspectos cruciales relativos a los recursos, la concurrencia y la memoria: Espacio de direcciones: El nuevo proceso adquiere un duplicado exacto del espacio lógico del creador (véase «Concepto de Proceso, PCB y Hilos de Ejecución»), abarcando las secciones de código, datos globales y la pila de ejecución. No obstante, cada proceso dispone de su propia memoria física independiente. Cualquier modificación posterior en las variables del hijo no alterará las del padre ni viceversa. Contexto de ejecución: El hijo se inicializa compartiendo los mismos valores en los registros del procesador y el mismo puntero de instrucciones (Program Counter).

Por tanto, el hijo no reinicia el programa desde la función inicial, sino que comienza a ejecutarse exactamente en el punto donde se invocó fork. Planificación: Una vez finalizada la duplicación, ambos procesos quedan en disposición de competir por la CPU y se ejecutan de manera concurrente (véase «Estados del Proceso y Propiedades en Linux»).

El PID numérico a) Las variables como PATH o HOME b) Las credenciales UID y GID c) El contador de programa en registros d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 13 Para que el flujo del programa pueda diferenciar qué tareas corresponden a cada rol, la llamada al sistema fork() devuelve valores distintos en cada contexto: En el proceso padre, devuelve el PID del hijo recién creado (un valor entero estrictamente mayor que 0). En el proceso hijo, devuelve el valor 0. En caso de error por falta de memoria o por rebasar los límites del sistema, devuelve un valor negativo (-1) en el padre y el hijo no llega a crearse.

EJEMPLO Estructura habitual de control tras invocar una bifurcación: pid_t pid = fork(); if (pid < 0) { /* Gestión de error */ } else if (pid == 0) { /* Código exclusivo del hijo: ret devuelve 0 */ } else { /* Código exclusivo del padre: ret contiene el PID del hijo */ } ERROR FRECUENTE Omitir el control de salida en bucles con fork() . Si se ejecuta una llamada dentro de una iteración sin filtrar adecuadamente mediante un exit() en el hijo, tanto el padre original como todos los hijos creados continuarán iterando y bifurcándose en cada paso.

Por ejemplo, llamadas secuenciales a fork() sin control generan procesos totales, pudiendo desembocar en una bomba de procesos (fork bomb) que sature la tabla del núcleo e inutilice el sistema. Esquema de bifurcación jerárquica con y sin terminación con exit. COMPRUEBA 22 Si un proceso ejecuta tres llamadas a fork() consecutivas sin comprobaciones condicionales, ¿cuántos procesos existirán en total al terminar?

n 2n Gestión de Procesos: Apuntes de Sistemas Operativos FIB 14 Reglas de herencia tras la invocación de fork El hijo hereda la mayor parte de las características operativas y del entorno de su progenitor mediante una copia privada, pero ciertos identificadores y contadores deben reiniciarse para preservar la integridad del sistema operativo. Elemento o recurso Comportamiento en fork() Detalles operativos Espacio lógico de memoria Se clona Copia independiente de código, datos y pila. Tabla de señales Se hereda Mantiene las rutinas y acciones configuradas previamente. Variables de entorno Se clonan Entorno idéntico en el momento de la creación.

Credenciales y privilegios Se heredan Mismo usuario y grupo que el padre. Dispositivos virtuales Se heredan Descriptores y canales abiertos se mantienen compartidos. Identificador de proceso (PID) No se hereda Recibe un identificador único asignado por el sistema. Identificador del padre (PPID) No se hereda Se actualiza con el PID del proceso llamador. Alarmas y señales pendientes No se heredan Se inicializan a cero de forma exclusiva para el hijo. Contadores de uso de recursos No se heredan Las métricas de consumo (accounting) se reinician a cero.

Para consultar sus identidades, los procesos disponen de las llamadas de consulta del sistema: getpid() obtiene el identificador propio y getppid() devuelve el identificador del proceso progenitor. COMPRUEBA 23 ¿Por qué el hijo no hereda las señales pendientes ni las alarmas del padre? Terminación con exit y sincronización con waitpid La finalización de un proceso puede producirse de dos maneras: Voluntaria: El proceso invoca explícitamente la llamada al sistema exit(int status) , o finaliza retornando desde el bloque principal. Con ello devuelve un código de terminación al sistema.

Involuntaria: Una señal no interceptada o una excepción hardware obliga al núcleo a abortar el proceso de manera inmediata (véase «Comunicación entre Procesos y Manejo de Señales POSIX»). Gestión de Procesos: Apuntes de Sistemas Operativos FIB 15 Al concluir, el sistema operativo desaloja inmediatamente su memoria y cierra sus recursos abiertos. Sin embargo, no puede eliminar por completo su estructura de control en el núcleo (véase el PCB en «Concepto de Proceso, PCB y Hilos de Ejecución»). El proceso pasa al estado ZOMBIE (proceso difunto), reteniendo su PID y el código de terminación en la tabla de procesos hasta que el padre proceda a su recogida.

DEFINICIÓN Un proceso ZOMBIE es aquel que ha completado su ejecución pero cuyo PCB permanece en el kernel a la espera de que su padre lea el estado de finalización mediante wait() o waitpid() . Para sincronizarse con el hijo y recoger este código, el padre utiliza las llamadas de espera. La más versátil es waitpid(pid_t pid, int *status, int options) . Es una llamada potencialmente bloqueante que cambia el estado del padre de RUN a BLOCKED mientras el hijo continúa activo. Esquema de comportamiento y bloqueo en la llamada waitpid. El comportamiento de waitpid depende de los parámetros suministrados: Si se pasa , espera la finalización de cualquier hijo.

Si se indica un valor específico , espera a ese hijo en concreto. El argumento options permite variar la política. Con , la llamada es bloqueante si el hijo sigue vivo. Con el flag WNOHANG, la llamada no se bloquea: si el hijo sigue en ejecución, waitpid retorna inmediatamente el valor 0 sin pausar al padre. Cuando un proceso padre finaliza antes que sus hijos sin recolectarlos, el proceso init (PID 1) los adopta de forma automática. El proceso init se encarga de ejecutar llamadas wait continuas para enterrar a estos procesos huérfanos y liberar sus entradas de la tabla del núcleo.

pid = 1 pid = pid ijo h options = 0 Gestión de Procesos: Apuntes de Sistemas Operativos FIB 16 PROCESO Ciclo de vida del proceso en UNIX COMPRUEBA 24 ¿Qué ocurre con los descriptores y el espacio de memoria de un proceso cuando se convierte en zombie? Mutación del ejecutable mediante la familia exec Mientras que fork() clona el proceso existente, la familia de funciones exec (como por ejemplo execlp ) permite sustituir por completo el programa en ejecución dentro de ese mismo proceso. DEFINICIÓN La mutación de un proceso mediante exec consiste en reemplazar la imagen de memoria del proceso actual por un nuevo binario ejecutable cargado desde disco, sin cambiar la identidad del proceso.

La firma genérica de la llamada en C es: int execlp(const char *file, const char *arg, ...); Cuando se ejecuta con éxito, execlp opera de la siguiente manera: Espacio de direcciones: Se destruye y reemplaza íntegramente. El código, datos y pila son sobreescritos por los del nuevo programa. Puntero de instrucciones: Se reinicia al inicio del nuevo binario (generalmente la función main ). Como el código original desaparece, las instrucciones posteriores a un exec exitoso nunca se ejecutan. Clonación (fork) El padre crea un duplicado exacto con memoria independiente. 1 Ejecución activa El proceso ejecuta sus tareas o muta su binario con exec.

2 Terminación (exit) Libera sus recursos de memoria pero retiene el PCB en el núcleo. 3 Estado zombie Permanece registrado hasta que el padre atiende su código de salida. 4 Recolección (waitpid) El padre recoge el código final y el kernel retira el PCB. 5 Gestión de Procesos: Apuntes de Sistemas Operativos FIB 17 Identidad y contexto: Se preserva el mismo PID y PPID, así como los contadores internos de recursos y señales pendientes. Gestión de señales: Las rutinas específicas asignadas a señales en el programa anterior se descartan y se restablece el comportamiento por defecto del sistema (véase «Comunicación entre Procesos y Manejo de Señales POSIX»).

ESQUEMA Impacto de fork y exec en los atributos COMPRUEBA 25 Si una llamada a execlp() se ejecuta de manera exitosa, ¿qué valor entero devuelve a la variable receptora?

Atributos del proceso Gestión del estado interno según la llamada Duplicados por fork Clonados en una copia privada independiente Memoria y señales Código, datos, pila y manejadores de señales Reiniciados por fork Asignados de nuevo de manera unívoca PID y métricas Nuevo PID, PPID y contadores a cero Preservados por exec Identidad conservada durante la mutación PID y contadores El proceso conserva su identidad original Reiniciados por exec Sustituidos por la nueva imagen cargada Memoria y código Espacio lógico y Program Counter al inicio Gestión de Procesos: Apuntes de Sistemas Operativos FIB 18 IDEAS CLAVE La llamada fork() bifurca el proceso clonando su espacio lógico pero manteniendo memorias físicas separadas.

fork() devuelve el PID del hijo al padre y 0 al hijo, lo que permite dividir la lógica del código de ejecución. Un proceso finalizado con exit entra en estado ZOMBIE hasta que su padre recoge su código de salida con wait o waitpid. Si un padre muere sin recoger a sus descendientes, el proceso init los adopta y desahucia sus PCBs. La función exec muta el ejecutable reiniciando el espacio de direcciones y la pila, pero conservando el mismo identificador de proceso (PID). COMPRUEBA LO QUE HAS APRENDIDO 26. ¿En qué se diferencia el retorno de fork() en el proceso padre respecto al proceso hijo? 27. ¿Qué utilidad ofrece el indicador WNOHANG al ejecutar la llamada al sistema waitpid? 28.

¿Qué atributos del proceso se mantienen invariables tras invocar con éxito una llamada de la familia exec? Test Rodea la respuesta correcta. Las soluciones están al final. 29. ¿Qué valor retorna la llamada al sistema fork() en el proceso hijo recién creado? 30. ¿Qué recurso NO hereda un proceso hijo tras la ejecución de fork()? 31. ¿Qué condición mantiene a un proceso en estado zombie en la tabla del sistema operativo? 32. ¿Qué sucede con el PID de un proceso cuando invoca satisfactoriamente execlp()?

El número 0 a) El PID del proceso padre b) El propio PID del hijo c) El valor -1 d) Las credenciales de usuario y grupo a) El espacio de direcciones lógico b) Las variables de entorno c) Las alarmas y señales pendientes d) Haber mutado su código con exec a) Haber realizado un bucle infinito b) No haber sido recogido por waitpid c) Estar bloqueado esperando lectura en disco d) El PID se reinicia a 0 a) El sistema genera un PID nuevo b) Pasa a ser el PID de init c) Se conserva exactamente el mismo PID d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 19 4 Comunicación entre Procesos y Manejo de Señales POSIX AL ACABAR SABRÁS Diferenciar los modelos y mecanismos de IPC disponibles en sistemas operativos Linux.

Configurar el manejo de señales mediante sigaction y las funciones de manipulación de máscaras. Analizar la gestión interna de señales en el PCB respecto a pendientes, bloqueos y acciones. Determinar el estado de las señales y sus manejadores tras llamadas a fork y exec. PIÉNSALO ANTES DE LEER 33 ¿Por qué el sistema operativo no acumula en un contador las veces que llega una misma señal mientras un proceso la tiene bloqueada? Modelos de comunicación entre procesos (IPC) Los procesos de un sistema operativo pueden ejecutarse de manera independiente o cooperar para acelerar cómputos, compartir datos o modularizar una aplicación (véase «Concepto de Proceso, PCB y Hilos de Ejecución»).

La comunicación entre procesos (Interprocess Communication o IPC) provee los cauces para intercambiar datos o estados. Existen dos arquitecturas conceptuales básicas para transferir información: Memoria compartida (Shared memory): dos o más procesos acceden a una misma región de memoria física donde leen y escriben variables comunes sin intermediación directa del núcleo en cada acceso. Paso de mensajes (Message passing): los procesos emplean primitivas del sistema operativo para transferir bloques de datos mediante funciones explícitas de envío y recepción.

Linux ofrece diversos mecanismos de IPC adaptados a diferentes necesidades de concurrencia y comunicación: Mecanismo Ámbito Naturaleza del canal Signals Local (mismo equipo) Notificaciones asíncronas de eventos breves enviadas por el kernel o por procesos del mismo usuario. Pipes Local (procesos emparentados) Canal unidireccional primero en entrar, primero en salir (FIFO) usado comúnmente para encadenar comandos en la shell. FIFOs Local (sistema de archivos) Pipes con nombre dentro del sistema de ficheros accesibles por cualquier proceso con permisos. Sockets Local y Red Comunicación bidireccional entre extremos locales o a través de redes remotas.

Gestión de Procesos: Apuntes de Sistemas Operativos FIB 20 Mecanismo Ámbito Naturaleza del canal Message queues Local Colas indirectas para almacenar y despachar mensajes estructurados. Semaphores Local Contadores compartidos para controlar el acceso y evitar colisiones sobre recursos concurrentes. COMPRUEBA 34 ¿En qué se diferencia el modelo de memoria compartida del de paso de mensajes a nivel de intervención del sistema operativo durante la transferencia? Señales POSIX: naturaleza y ciclo de vida Una señal es una interrupción por software enviada a un proceso para notificarle un suceso asíncrono.

Puede originarse en el núcleo debido a una anomalía o temporizador, o bien en otro proceso que pertenezca al mismo usuario. Al llegar la señal, el flujo de ejecución normal se interrumpe y el procesador pasa a ejecutar la acción programada en el tratamiento de dicha señal. Al terminar, la ejecución retoma el punto donde fue pausada, salvo que la acción haya provocado la terminación del proceso. Esquema del flujo de entrega de una señal a través del kernel.

Cada tipo de evento cuenta con un número entero asignado en /usr/include/bits/signum.h y constantes simbólicas estandarizadas: Señal Acción por defecto Causa o evento habitual SIGCHLD Ignorar (IGN) Un proceso hijo ha terminado o se ha detenido. SIGCONT Continuar Reanudar la ejecución si el proceso estaba parado. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 21 Señal Acción por defecto Causa o evento habitual SIGSTOP Parar proceso (STOP) Detener el proceso inmediatamente; no capturable ni bloqueable. SIGINT Terminar Interrupción interactiva solicitada por teclado (Ctrl+C). SIGALRM Terminar Vencimiento del temporizador programado con alarm() .

SIGKILL Terminar Finalización forzosa inmediata; no capturable ni bloqueable. SIGSEGV Terminar + Core Acceso no válido a memoria (fallo de segmentación). SIGUSR1 Terminar Propósito general definido libremente por el programador. SIGUSR2 Terminar Propósito general definido libremente por el programador. PARA RECORDARLO Las señales SIGKILL y SIGSTOP no se pueden ignorar, capturar ni bloquear. Su ejecución directa por parte del sistema operativo garantiza que el administrador siempre pueda parar o destruir cualquier proceso. COMPRUEBA 35 ¿Qué dos señales estándar de UNIX están completamente reservadas para que el programador defina su significado y uso libre?

Estructuras del PCB y manipulación de máscaras La gestión de señales reside en el Process Control Block (PCB) del proceso (véase «Concepto de Proceso, PCB y Hilos de Ejecución»). El núcleo gestiona tres componentes esenciales por proceso: Tabla de tratamiento de señales: un registro por cada señal que asocia la acción a realizar (ignorar, acción por defecto o función de usuario). Máscara de señales bloqueadas: un mapa de bits que especifica qué señales deben quedar en espera si son entregadas. Bitmap de señales pendientes: almacena si hay una señal en espera de ser atendida (1 bit por tipo de señal, sin acumulación numérica).

ERROR FRECUENTE Asumir que si un proceso recibe cuatro veces una misma señal mientras la tiene bloqueada, el manejador se ejecutará cuatro veces al desbloquearla. El bitmap de señales pendientes almacena un indicador booleano de 1 bit: las señales estándar no se acumulan y solo se entregará un único evento al retirar el bloqueo. Para manipular el tipo de datos sigset_t (máscaras de señales) en el estándar POSIX se emplean funciones auxiliares: sigemptyset(sigset_t *set) : limpia la máscara inicializándola sin ninguna señal activa. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 22 sigfillset(sigset_t *set) : añade todas las señales del sistema a la máscara.

sigaddset(sigset_t *set, int signum) : añade la señal concreta signum a la máscara. sigdelset(sigset_t *set, int signum) : suprime signum de la máscara. sigismember(const sigset_t *set, int signum) : verifica si signum forma parte del conjunto actual. La aplicación o consulta de la máscara de bloqueo en el PCB se realiza mediante la llamada al sistema sigprocmask(int operation, const sigset_t *mask, sigset_t *oldmask) , donde el argumento operation puede ser: COMPRUEBA 36 ¿Qué ocurre en el PCB si se envían repetidamente varias señales idénticas mientras esa señal está incluida en la máscara de bloqueo?

Instalación de manejadores con sigaction y envío de señales Para emitir señales entre procesos se invoca la llamada al sistema kill(pid_t pid, int signum) , la cual requiere conocer el PID del destinatario y poseer los permisos adecuados. Esquema de sincronización entre procesos mediante llamadas kill y sigaction.

Para configurar cómo debe reaccionar el proceso al recibir un evento, la interfaz POSIX implementa sigaction() , superando las ambigüedades e incompatibilidades de llamadas históricas: int sigaction(int signum, const struct sigaction *tratamiento, struct sigaction *tratamiento_antiguo); El comportamiento se describe en los campos de la estructura struct sigaction : sa_handler: puntero que acepta tres modalidades: SIG_IGN : descarta e ignora la señal al recibirla. SIG_DFL : restablece la acción estándar asignada por el sistema. SIG_BLOCK: añade las señales contenidas en mask a la máscara activa del proceso (unión lógica).

1 SIG_UNBLOCK: elimina las señales de mask de la máscara activa del proceso. 2 SIG_SETMASK: reemplaza íntegramente la máscara actual por el contenido de mask . 3 Gestión de Procesos: Apuntes de Sistemas Operativos FIB 23 Puntero a función: ejecuta una rutina definida por el usuario con firma void nombre_funcion(int s); . El argumento entero s permite distinguir la señal recibida si se vincula un mismo manejador a varios eventos. sa_mask: máscara de señales adicionales que el kernel bloqueará automáticamente de forma temporal durante la ejecución del manejador. Al salir de la rutina, el núcleo restaura la máscara original.

sa_flags: modificadores del comportamiento estándar: SA_RESETHAND : tras ejecutarse el manejador por primera vez, el sistema revierte el tratamiento a SIG_DFL . SA_RESTART : si una llamada al sistema bloqueante se vio interrumpida por la llegada de la señal, se reanuda de modo automático al finalizar la atención. Diagrama de opciones de configuración de tratamiento de señales en sigaction.

El siguiente esquema resume la bifurcación de tratamientos posibles y las directivas de configuración: Gestión de Procesos: Apuntes de Sistemas Operativos FIB 24 ESQUEMA Tratamiento de señales con sigaction COMPRUEBA 37 ¿Por qué la función de tratamiento de usuario recibe un parámetro entero si ya se asocia con sigaction a una señal en particular? Sincronización y espera: espera activa frente a sigsuspend Cuando un proceso debe detenerse hasta que otro le envíe una señal determinada, existen dos estrategias de diseño con repercusiones opuestas sobre el uso del hardware: Espera activa: el proceso ejecuta un bucle continuo comprobando una condición en memoria (ej. while(!recibido); ).

Consume ciclos de procesador innecesarios durante toda la espera. Solo se aconseja si el intervalo de espera es extremadamente breve y no compensa el coste de un cambio de contexto. Bloqueo del proceso: el proceso cede voluntariamente la CPU pasando a estado BLOCKED (véase «Estados del Proceso y Propiedades en Linux»), liberando el procesador para que otros procesos avancen. Cuando arriba la señal esperada, el núcleo despierta al proceso. Para pausar la ejecución de manera atómica sin caer en condiciones de carrera, se emplea sigsuspend(const sigset_t *mask) .

Esta llamada sustituye temporalmente la máscara activa por mask y suspende el proceso hasta que reciba una señal que no esté bloqueada en esa máscara temporal y cuyo tratamiento no sea SIG_IGN . Al concluir el manejador, sigsuspend() restituye de inmediato la máscara anterior. Asimismo, para la temporización se dispone de alarm(unsigned int num_secs) , la cual programa una alarma en el kernel para que entregue la señal SIGALRM al cabo de los segundos especificados.

Solo puede existir un único temporizador activo por proceso: si se invoca de nuevo, la llamada Tratamiento de señal Acción configurada en PCB Ignorar (SIG_IGN) El evento se descarta Por defecto (SIG_DFL) Acción predefinida del sistema Terminar proceso Finaliza la tarea Terminar y Core dump Vuelca imagen de memoria Parar proceso Pausa la ejecución Función de usuario Manejador definido por código Gestión de Procesos: Apuntes de Sistemas Operativos FIB 25 reprograma el plazo anulando el anterior. COMPRUEBA 38 ¿Qué beneficio aporta sigsuspend frente a desbloquear manualmente la señal con sigprocmask y luego llamar a una instrucción de espera?

Herencia de señales en fork y exec La creación de un nuevo proceso y la sustitución de la imagen de ejecución alteran las estructuras de señales del PCB de maneras muy distintas: Estructura en el PCB Comportamiento tras fork() Comportamiento tras exec() / execlp() Tabla de tratamientos Se hereda idéntica del padre. Se restablece por defecto (SIG_DFL) porque el código del ejecutable cambia. Máscara de bloqueo Se hereda idéntica del padre. Se conserva intacta sin modificaciones. Bitmap de pendientes Se vacía por completo (el hijo no tiene señales acumuladas). Se conserva (las señales pendientes se mantienen para el mismo PID).

Temporizadores (alarm) Se anulan; el hijo no hereda las alarmas pendientes. Se conservan las alarmas programadas previamente. PROCESO Impacto de fork y exec en señales 1 Proceso Padre Posee tratamientos, máscara y pendientes 2 Llamada fork() Hereda acciones y máscara; bo rra pendientes 3 Llamada exec() Restaura acciones a default; con serva máscara y pendientes La razón por la cual exec() revierte los tratamientos de las señales con función personalizada a SIG_DFL radica en que la mutación sustituye todo el espacio de memoria (código, datos y pila).

Dado que el código que contenía el manejador anterior deja de existir en el nuevo mapa de memoria, el puntero a la función queda invalidado, forzando al sistema a restaurar la acción predeterminada. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 26 IDEAS CLAVE Los signals son interrupciones por software empleadas para notificaciones asíncronas originadas por el sistema operativo o procesos afines. Las señales SIGKILL y SIGSTOP no pueden ser interceptadas, ignoradas ni bloqueadas bajo ninguna circunstancia. El bitmap de señales pendientes almacena un solo bit por señal, por lo que las señales estándar no poseen acumulación numérica.

La llamada sigaction permite modificar el tratamiento de señales (función propia, o ) y definir máscaras automáticas. La llamada sigsuspend reemplaza temporalmente la máscara de señales y bloquea el proceso de forma atómica para sincronizar sin consumo de CPU. Tras fork() se heredan tratamientos y máscaras pero se limpian las pendientes; tras exec() se restablecen las acciones a valores por defecto conservando máscara y pendientes. COMPRUEBA LO QUE HAS APRENDIDO 39. ¿Por qué un exec() restablece las acciones de las señales capturadas a SIG_DFL pero fork() mantiene las funciones de usuario? 40.

¿Por qué resulta ineficaz recurrir a la espera activa mediante un bucle while para aguardar una señal en sistemas multiprogramados? Test Rodea la respuesta correcta. Las soluciones están al final. 41. ¿Qué par de señales no se pueden bloquear, ignorar ni capturar mediante sigaction? 42. ¿Cómo gestiona el núcleo la llegada repetida de una misma señal estándar bloqueada? 43. ¿Qué ocurre con las señales pendientes tras ejecutar fork() frente a exec()? SIG_IGN SIG_DFL SIGINT y SIGSEGV a) SIGKILL y SIGSTOP b) SIGTERM y SIGCONT c) SIGUSR1 y SIGUSR2 d) Las almacena en una cola ordenada FIFO. a) Descarta todas las repeticiones provocando error. b) Incrementa un contador entero en el PCB.

c) Guarda un bit en el bitmap entregando solo una. d) fork las conserva y exec las borra. a) fork las borra y exec las conserva. b) Ambas llamadas borran las señales pendientes. c) Ambas llamadas conservan todas las pendientes. d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 27 44. ¿Cuál es la función principal de la llamada sigsuspend()? 5 Planificación de Procesos, Cambio de Contexto y Gestión del Kernel AL ACABAR SABRÁS Distinguir el funcionamiento y las estructuras de colas del planificador del kernel. Describir la secuencia y la sobrecarga asociadas al cambio de contexto. Calcular tiempos de espera máximos y analizar la influencia del cuanto en Round Robin.

Explicar el principio de equidad de CFS y el impacto interno de las llamadas al sistema. PIÉNSALO ANTES DE LEER 45 ¿Por qué un procesador pasa tiempo trabajando sin hacer avanzar ningún programa del usuario? Estructuras del kernel para la gestión de procesos Para administrar la ejecución concurrente, el sistema operativo necesita representar cada tarea y organizar el conjunto global. Cada proceso cuenta con un bloque de control de proceso o PCB (véase «Concepto de Proceso, PCB y Hilos de Ejecución»), el cual contiene su identificador, credenciales, estado actual, zona para salvar registros de la CPU, datos de señales, métricas de planificación y gestión de memoria o entrada/salida.

El núcleo no mantiene los PCB dispersos. Emplea estructuras de gestión dinámicas como vectores, listas enlazadas, tablas de dispersión o árboles para ordenarlos eficientemente según su estado: Lista general de procesos: agrupa la totalidad de procesos existentes en el sistema operativo. Cola de listos (ready queue): reúne los procesos preparados para usar la CPU (véase «Estados del Proceso y Propiedades en Linux»). En sistemas avanzados se divide en varias colas agrupadas por prioridades o clases. Colas de dispositivos de E/S: conjuntos de procesos suspendidos a la espera de una respuesta de un periférico concreto.

Cuando un dispositivo finaliza una transferencia, el kernel retira el proceso de la cola del periférico y lo reubica en la cola de listos. Finalizar de forma inmediata la ejecución del programa. a) Reemplazar la máscara y bloquear el proceso atómicamente. b) Cancelar definitivamente todas las señales del proceso. c) Comprobar en un bucle si una señal se ha emitido. d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 28 El planificador y las políticas de asignación El planificador o scheduler es el componente del kernel encargado de decidir qué proceso toma la CPU, en qué momento y durante cuánto tiempo.

Su activación es muy frecuente: típicamente evalúa el estado del procesador en cada interrupción periódica del reloj hardware (habitual cada 10 ms) para impedir monopolios del cómputo. Las decisiones de planificación se desencadenan ante dos modalidades de eventos: Eventos no preemptivos: el proceso en ejecución libera voluntariamente la CPU porque termina su tarea o solicita una operación bloqueante. Eventos preemptivos: el núcleo desaloja forzosamente al proceso de la CPU para otorgársela a otro según los criterios del algoritmo, pasando el primero a la cola de listos.

Un sistema operativo se clasifica según la naturaleza de sus decisiones: Tipo de política Comportamiento ante la CPU Eventos gestionados No preemptiva (no apropiativa) El proceso retiene el procesador hasta que finaliza o se bloquea voluntariamente. Únicamente eventos no preemptivos. Preemptiva (apropiativa) El kernel arrebata la CPU al proceso activo mediante interrupciones temporales o prioridades. Eventos preemptivos y no preemptivos. El comportamiento de los programas condiciona esta tarea: existen procesos de cálculo (intensivos en procesador) y procesos de entrada/salida (que alternan breves ráfagas de cálculo con esperas de dispositivos).

COMPRUEBA 46 ¿Por qué un planificador preemptivo requiere necesariamente el soporte de un temporizador hardware? Mecanismo de cambio de contexto (context switch) El paso de un proceso en ejecución a otro exige realizar un cambio de contexto. Este procedimiento salva el estado del proceso saliente en su PCB y restaura el estado del proceso entrante desde su respectivo PCB, permitiendo reanudar su ejecución justo donde quedó suspendido. Gestión de Procesos: Apuntes de Sistemas Operativos FIB 29 Esquema del cambio de contexto entre procesos mediante guardado en PCB.

El cambio de contexto no ejecuta instrucciones del usuario; supone una sobrecarga pura (overhead) que debe minimizarse con ayuda del hardware. Si la conmutación se realiza entre hilos de un mismo proceso, el coste es menor que entre procesos distintos, ya que los primeros comparten el espacio de direcciones. PROCESO Secuencia de un cambio de contexto en el kernel Interrupción de reloj El temporizador hardware cede el control al sistema operativo. 1 Salvar contexto A Se copian los registros de la CPU en el PCB de A. 2 Elección del planificador El algoritmo escoge al proceso B de la cola de listos. 3 Restaurar contexto B Se cargan los registros del procesador desde el PCB de B.

4 Ejecución de usuario El procesador reanuda las instrucciones del proceso B. 5 Gestión de Procesos: Apuntes de Sistemas Operativos FIB 30 ERROR FRECUENTE Confundir el tiempo invertido en el cambio de contexto con tiempo de cómputo útil. Durante la conmutación de contexto solo se ejecutan rutinas internas del kernel para preservar y restaurar registros del PCB; si el intervalo de asignación de CPU es excesivamente pequeño, el sistema desperdicia la mayor parte de su capacidad en sobrecarga administrativa en vez de procesar tareas.

Métricas de rendimiento y algoritmos de planificación Para valorar la eficacia del planificador se analizan dos métricas temporales fundamentales: Tiempo de retorno (turnaround time): duración total transcurrida desde que el proceso ingresa al sistema hasta que concluye definitivamente, sumando todos sus estados. Depende de las características del propio proceso y de la carga global del sistema. Tiempo de espera: tiempo agregado que el proceso permanece aguardando dentro de la cola de listos. Round Robin (RR) El algoritmo Round Robin gestiona los procesos de la cola de listos mediante una política FIFO estricta.

A cada proceso se le asigna un intervalo fijo de procesador denominado cuanto de tiempo o time quantum, habitualmente fijado entre 10 y 100 milisegundos. Se trata de un esquema puramente preemptivo activado por tres causas: Si compiten procesos con un cuanto , la fracción de uso asignada es de del procesador en bloques máximos de . Así, ningún proceso espera más de en la cola de listos. El ajuste del valor resulta crítico para el rendimiento: Cuanto muy grande: el algoritmo degenera en un esquema de procesamiento por orden de llegada (secuencial). Cuanto muy pequeño: la sobrecarga producida por continuos cambios de contexto penaliza gravemente la CPU.

Debe mantenerse holgadamente superior al coste del cambio de contexto. Completely Fair Scheduler (CFS) El planificador estándar de Linux, Completely Fair Scheduler (CFS), busca corregir el desequilibrio de Round Robin frente a procesos dependientes de entrada/salida. Su meta consiste en lograr un tiempo de cómputo equivalente entre todos los procesos concurrentes. Bloqueo del proceso (no preemptivo): pasa a la cola de bloqueados del dispositivo correspondiente. 1 Terminación del proceso (no preemptivo): finaliza y pasa a estado zombie en Linux a la espera de su recogida.

2 Agotamiento del cuanto (preemptivo): la interrupción de reloj desaloja al proceso y lo reinserta al final de la cola de listos. 3 N Q 1/N Q (N 1) × Q Q Gestión de Procesos: Apuntes de Sistemas Operativos FIB 31 En lugar de emplear un valor estático, utiliza un cuanto dinámico. Divide el tiempo de ejecución entre la cantidad de procesos listos para competir. Un proceso conserva la CPU hasta que se bloquea, acaba o iguala su cuota teórica. La prioridad se otorga en función de la distancia al tiempo teórico: cuanto más rezagado esté un proceso respecto a su cuota ideal, mayor preferencia tiene para ser ejecutado.

Asimismo, CFS permite definir grupos de procesos configurables por el administrador. Esta agrupación impide que un usuario que lance multitud de procesos acapare el tiempo de la máquina en detrimento de los demás. COMPRUEBA 47 En Round Robin con 5 procesos listos y un cuanto de 20 ms, ¿cuál es el tiempo máximo que esperará un proceso para recuperar la CPU?

Impacto interno de las llamadas al sistema en las estructuras del kernel Las llamadas al sistema del ciclo de vida modifican profundamente las tablas y colas internas: fork: localiza y reserva una entrada libre en la tabla de PCB, inicializa identificadores propios (como el nuevo PID), configura la gestión de memoria y entrada/salida, y añade el proceso hijo a la cola de listos. No hereda alarmas ni eventos pendientes del temporizador del padre. exec (execlp): sustituye el espacio de direcciones previo cargando el nuevo ejecutable.

Reinicia la tabla de señales a sus acciones por defecto, conservando la máscara de señales bloqueadas, la lista de eventos pendientes y los identificadores (véase «Ciclo de Vida del Proceso: fork, exec, exit y waitpid»). exit: libera los recursos asociados al proceso (espacio de memoria y periféricos en uso), actualiza su estado a zombie registrando el código de salida en su PCB, lo retira de las colas de planificación e invoca al planificador para seleccionar otro candidato. waitpid: examina la estructura del proceso hijo; si se encuentra en estado zombie, extrae su código final, desasigna definitivamente su PCB y lo devuelve al padre.

Si el hijo continúa activo, el kernel transfiere al padre de RUN a BLOCKED y ejecuta una nueva planificación. IDEAS CLAVE El kernel gestiona los procesos organizando sus PCB en la cola general, la cola de listos y las colas de entrada/salida. El planificador preemptivo evalúa la CPU periódicamente mediante interrupciones de reloj, típicamente cada 10 ms. El cambio de contexto guarda y recupera el estado hardware en el PCB y representa sobrecarga de procesador. En Round Robin con N procesos y cuanto Q, el tiempo máximo de espera en la cola de listos es de . El algoritmo CFS de Linux persigue repartir equitativamente el cómputo y prioriza al proceso más alejado de su cuota teórica.

(N 1) × Q Gestión de Procesos: Apuntes de Sistemas Operativos FIB 32 COMPRUEBA LO QUE HAS APRENDIDO 48. ¿Qué consecuencia tiene asignar un cuanto de tiempo excesivamente reducido en Round Robin? 49. ¿En qué difieren las políticas de planificación preemptivas de las no preemptivas? Test Rodea la respuesta correcta. Las soluciones están al final. 50. ¿Qué estructura del sistema operativo preserva el estado hardware durante un cambio de contexto? 51. En Round Robin con 4 procesos listos y un cuanto de 10 ms, ¿cuánto espera como máximo un proceso? 52. ¿Cuál es la métrica directriz que CFS utiliza para seleccionar el proceso a ejecutar? 53.

¿Qué acción interna realiza el kernel sobre el PCB del proceso hijo durante un waitpid exitoso?

El registro de interrupción periódica a) La tabla de descriptores de archivos b) La cola de procesos bloqueados c) El bloque de control de proceso d) 10 ms a) 30 ms b) 120 ms c) 40 ms d) Mayor distancia respecto al tiempo teórico a) Menor tiempo restante de ejecución b) Número de descriptores de E/S abiertos c) Orden cronológico estricto de llegada d) Reubica el PCB en la cola de listos a) Reinicia los contadores y mantiene el PCB b) Extrae su estado final y libera el PCB c) Copia el PCB en el espacio de usuario d) Gestión de Procesos: Apuntes de Sistemas Operativos FIB 33 6 Protección y Seguridad en el Sistema Operativo AL ACABAR SABRÁS Diferenciar los conceptos de protección interna y seguridad frente a amenazas externas.

Explicar el modelo de permisos POSIX (rwx) para propietario, grupo y otros usuarios. Comprender el funcionamiento y propósito del mecanismo setuid y del usuario root. Identificar los cuatro niveles de seguridad de un sistema informático y sus medidas clave. PIÉNSALO ANTES DE LEER 54 ¿Por qué un usuario estándar puede actualizar su contraseña si el archivo que guarda los datos solo lo puede modificar el administrador?

Protección frente a seguridad Aunque a menudo se emplean como sinónimos, en sistemas operativos representan dos ámbitos complementarios con enfoques distintos: La protección comprende los mecanismos internos del sistema diseñados para controlar y regular el acceso de los procesos o usuarios a los recursos del propio sistema informático (memoria, ficheros, dispositivos). La seguridad abarca las…