Procesos y llamadas al sistema

Un navegador, un compilador y un reproductor de música pueden avanzar en un mismo computador. Cada uno necesita tiempo de CPU, memoria y acceso a dispositivos. El sistema operativo (SO) proporciona esos recursos mediante servicios que los programas pueden usar sin controlar toda la máquina.

Proporcionar recursos útiles a los programas

La virtualización convierte un recurso físico en un recurso virtual cómodo de usar. La virtualización de la CPU permite que muchos procesos se comporten como si cada uno tuviera su propio procesador. El SO ejecuta cada uno durante un tiempo y conserva su estado entre turnos. La virtualización de la memoria da a cada proceso su propio espacio de direcciones: las direcciones que pueden usar sus instrucciones.

Una abstracción oculta detalles detrás de una interfaz útil. Un archivo es una abstracción de bytes almacenados. Un programa puede llamar a write sin saber si esos bytes van a una unidad SSD o a una unidad de red. Una llamada al sistema proporciona una forma controlada de solicitar un servicio del núcleo. El trabajo específico del dispositivo queda detrás de la interfaz.

Compartir recursos y proteger programas

Como gestor de recursos, el SO decide quién obtiene tiempo de CPU, memoria y servicio de los dispositivos. Intenta mantener el hardware en uso y, al mismo tiempo, dar a los programas un acceso razonable. Compartir también requiere protección: un programa no debe sobrescribir la memoria privada de otro ni desactivar el temporizador para retener la CPU.

El hardware ayuda a imponer este límite. Las instrucciones de las aplicaciones se ejecutan en modo usuario con permisos limitados. El código del núcleo se ejecuta con los privilegios necesarios para gestionar la máquina. Un temporizador puede interrumpir un programa aunque este nunca solicite nada al SO.

Para una computadora portátil que descarga un archivo mientras compila código, sigue tres tareas distintas:

1. El dispositivo de red informa de la llegada de datos. El núcleo los pone a disposición del proceso que realiza la descarga.
2. El SO comparte el tiempo de CPU entre el navegador, el compilador y otros procesos listos.
3. El compilador solicita operaciones de archivo para almacenar su salida. Su código no controla directamente el controlador de almacenamiento.

Separar el núcleo de la interfaz

El núcleo es la parte central privilegiada. El intérprete de comandos, el escritorio y la mayoría de las bibliotecas del sistema se ejecutan como programas normales, incluso cuando se distribuyen con el SO. Cerrar una ventana del escritorio no elimina el núcleo. Un servidor sin interfaz gráfica sigue necesitando gestión de procesos, protección de memoria y servicios de dispositivos.

En una CPU lógica, el código de usuario y el código del núcleo se turnan. Mientras el compilador ejecuta instrucciones normales de usuario, el núcleo no se está ejecutando también en esa CPU. Las llamadas al sistema, las excepciones y las interrupciones de hardware le devuelven el control.

Elegir cómo y después a quién

Un mecanismo proporciona una operación; una política elige cómo usarla. Guardar los registros de un proceso y restaurar los de otro es un mecanismo. Elegir qué proceso listo obtiene el siguiente turno es una política. Mantenerlos separados permite al SO cambiar sus decisiones de planificación sin reemplazar el mecanismo de cambio.

El diseño de un SO equilibra abstracciones útiles, rendimiento, protección, fiabilidad, seguridad y consumo de energía. El tiempo de CPU y la memoria adicionales dedicados a la gestión son sobrecarga. En toda la materia aparecen tres temas recurrentes: la virtualización, la concurrencia (actividades en curso al mismo tiempo) y la persistencia, que conserva los datos almacenados más allá de la vida de un programa o de una pérdida de alimentación.

Los sistemas operativos evolucionaron a medida que los computadores pasaron de ejecutar trabajos aislados a atender muchas actividades a la vez. Cada cambio resolvió un problema práctico: hardware inactivo, interacción lenta o fallos que se propagaban entre programas.

De los lotes al trabajo solapado

En el procesamiento por lotes, los trabajos enviados se ejecutan uno tras otro sin interacción con quien los envió. Los primeros programas de soporte ayudaban principalmente a cargar trabajos y realizar operaciones comunes de entrada/salida. Si el trabajo actual tenía que esperar a un dispositivo, la CPU podía quedar inactiva.

La multiprogramación mantiene varios trabajos en memoria. Cuando uno se bloquea por una operación de entrada/salida, otro puede realizar cálculos. Supón que un trabajo calcula repetidamente durante 20 ms y espera 80 ms a una operación de entrada/salida de disco. Por sí solo, su utilización de CPU es 20 / 100 = 20 %. Con dos trabajos así y un solapamiento adecuado, los cálculos útiles pueden ocupar el 40 % del tiempo transcurrido. La demora del dispositivo no se ha reducido; se ha ocupado tiempo de CPU que, de otro modo, habría quedado inactivo.

La ganancia depende de que haya trabajo listo. Añadir trabajos no puede elevar la utilización de la CPU por encima del 100 %, y los trabajos que esperan al mismo dispositivo aún pueden encontrarse con un cuello de botella. Varios trabajos en memoria también necesitan protección: uno no debe sobrescribir a otro ni dañar los datos del propio SO.

Hacer que la interacción sea rápida

El tiempo compartido da a los procesos turnos cortos en la CPU. Una terminal o un escritorio puede responder mientras otros programas siguen trabajando. Esperar a que termine un trabajo por lotes antes de atender la pulsación de una tecla de otro usuario daría una experiencia muy distinta.

La concurrencia significa que varias actividades están en curso durante el mismo periodo. Sus instrucciones pueden intercalarse en una CPU lógica. El paralelismo significa que las instrucciones se ejecutan realmente de forma simultánea en distintos recursos de procesamiento. La multiprogramación no requiere hardware paralelo.

Situar los servicios dentro o fuera del núcleo

Linux es monolítico y puede cargar módulos del núcleo. MINIX 3, QNX y seL4 ilustran diseños de micronúcleo. Windows NT y XNU de Apple suelen describirse como diseños híbridos. A menudo puede reiniciarse un controlador en modo usuario después de un fallo, mientras que un controlador privilegiado tiene acceso que puede hacer que su fallo afecte a todo el sistema.

Los primeros sistemas para computadores personales, como MS-DOS y el Mac OS clásico, carecían de la protección de memoria de los procesos que se espera hoy. Los sistemas modernos combinan las reglas del SO con la aplicación de esas reglas mediante hardware. Los turnos cortos de CPU por sí solos no impedirían que un programa modificara la memoria de otro; la compartición y la protección resuelven partes distintas del problema.

Un ejecutable en disco puede iniciarse repetidamente. Cada ejecución necesita su propio estado cambiante para que una instancia pueda pausarse, reanudarse o fallar de forma independiente. Esa instancia activa es un proceso.

Identificar la instancia en ejecución

Un programa consiste en instrucciones y datos estáticos almacenados. Un proceso combina un programa con su memoria, registros de CPU y estado de entrada/salida actuales. Tres intérpretes de comandos pueden ejecutar el mismo archivo ejecutable mientras mantienen distintas variables, directorios actuales e historiales.

El contador de programa (PC) identifica la siguiente instrucción. El puntero de pila localiza la pila activa. Los registros generales contienen valores intermedios. Cuando un proceso deja de ejecutarse, debe conservarse suficiente estado para que continúe en la instrucción correcta con los valores correctos.

Interpretar la organización del espacio de direcciones

El espacio de direcciones de un proceso es la memoria que pueden direccionar sus instrucciones. Una organización didáctica habitual sitúa el código y los datos estáticos hacia las direcciones más bajas, un montículo por encima y una pila hacia las direcciones más altas. El montículo da soporte a los objetos asignados dinámicamente; la pila da soporte a las llamadas a funciones y al estado local. En esta organización, el montículo crece hacia direcciones más altas y la pila hacia direcciones más bajas. Las organizaciones reales dependen del sistema y las implementaciones de malloc pueden obtener memoria de más de una manera.

Dos procesos pueden imprimir la misma dirección virtual para una variable y, aun así, contener valores distintos en ella. Las direcciones virtuales pertenecen a la vista de memoria de un proceso. Que los números de dirección coincidan no implica que exista almacenamiento escribible compartido.

Iniciar un programa

Para iniciar una nueva imagen de programa, el SO prepara estos elementos:

1. Su código y datos ejecutables, cuyas partes se cargan cuando se necesitan en los sistemas modernos.
2. Una pila de usuario inicial e información de arranque, incluidas las cadenas de argumentos y el vector de argumentos que usa el entorno de ejecución para llamar a main.
3. Memoria para la asignación dinámica y el estado inicial de los registros.
4. Un entorno de entrada/salida, incluidos los descriptores de archivo heredados.
5. Un punto de entrada donde comienza el código de inicio del programa.

En Unix, los descriptores de archivo son enteros pequeños que identifican recursos de entrada/salida abiertos. Por convenio del intérprete de comandos, 0 es la entrada estándar, 1 la salida estándar y 2 el error estándar. A menudo están conectados a una terminal. Un proceso puede heredar descriptores adicionales; los tres números conocidos no son un límite ni una garantía de que todos los procesos los tengan siempre abiertos.

Examinar el registro del núcleo

El bloque de control de proceso (PCB) registra la información que el núcleo necesita para gestionar un proceso: PID, estado, contexto de ejecución guardado, información de memoria, descriptores abiertos, padre, propietario, directorio actual e información de contabilidad. Linux usa task_struct; xv6 usa struct proc. Una tabla o lista de procesos organiza estos registros.

Mientras un proceso se ejecuta, sus registros activos están en la CPU. Al entrar en el núcleo, sus registros de usuario se guardan en su pila del núcleo; un cambio de contexto también conserva el contexto de ejecución del núcleo. El PCB no es una copia actualizada continuamente de cada registro de usuario.

Por ejemplo, un listado de ps en Linux podría contener 8240 8200 S bash y 8291 8240 R ps. El segundo proceso tiene el PID 8291 y el PID de su padre es 8240, por lo que es hijo del intérprete de comandos. R abarca tanto los procesos en ejecución como los listos. Un PID identifica a un proceso activo dentro de su espacio de nombres de PID, pero después de liberar sus recursos ese número puede reutilizarse.

Un proceso puede existir sin estar ejecutando una instrucción en ese momento. Su estado indica al SO si puede usar una CPU o si primero debe esperar otra cosa. Esta distinción explica por qué un computador ocupado puede tener muchos procesos, pero solo unos pocos ejecutándose en un instante dado.

Determinar qué necesita el proceso

Un proceso bloqueado no consume tiempo de CPU mientras está bloqueado. Su dispositivo o evento puede seguir avanzando. Un proceso listo ya tiene lo que necesita salvo una CPU.

Las transiciones básicas son listo → en ejecución cuando se selecciona, en ejecución → listo cuando se retira de la CPU, en ejecución → bloqueado cuando debe esperar y bloqueado → listo cuando ocurre su evento. La finalización del evento permite que un proceso pueda ejecutarse; no le concede la CPU inmediatamente. Elegir entre los procesos que pueden ejecutarse es tarea del planificador.

Seguir el trabajo solapado

Usa una CPU lógica e ignora la sobrecarga del cambio. El proceso A calcula durante 2 ms, espera 3 ms a una operación de entrada/salida de disco y luego calcula durante 1 ms. El proceso B necesita 4 ms de tiempo de CPU. A empieza primero.

A los 2 ms, A inicia la operación de entrada/salida y se bloquea. B calcula mientras trabaja el disco. A los 5 ms, termina la operación de entrada/salida de A, pero el SO deja que B complete su cuarto milisegundo de CPU antes de ejecutar A. Esta es una decisión de política, no una transición adicional directa de bloqueado a en ejecución.

El trabajo total de CPU es 2 + 1 + 4 = 7 ms y ambos terminan después de 7 ms. Si A se ejecutara hasta terminar antes de que comenzara B, el tiempo transcurrido sería 2 + 3 + 1 + 4 = 10 ms. La utilización de la CPU sería 7 / 10 = 70 %, porque ningún otro trabajo ocuparía la espera de entrada/salida.

Interpretar los estados en un sistema real

En Linux, ps combina los estados en ejecución y listo como R. Muestra el sueño interrumpible como S, el sueño ininterrumpible, a menudo por entrada/salida, como D, un proceso detenido como T y un proceso terminado pero no recolectado como Z. Un proceso detenido no está simplemente esperando la finalización de una operación normal de entrada/salida. Un zombi ha terminado de ejecutarse y solo conserva el registro necesario para comunicar su resultado.

Un proceso nuevo también pasa por la creación antes de estar listo. En un sistema con cuatro CPU lógicas, como máximo cuatro procesos de un solo hilo pueden ejecutarse simultáneamente. Las colas de procesos listos organizan el trabajo que puede ejecutarse; las listas de bloqueados registran los eventos que necesitan los procesos. Un cambio de contexto conserva el estado de ejecución de un proceso y restaura el de otro cuando el SO cambia el proceso que se ejecuta.

fork() crea un proceso hijo a partir del proceso padre que realiza la llamada. Ambos continúan inmediatamente después de la llamada, por lo que una ruta del código fuente da lugar a dos ejecuciones. El valor de retorno indica a cada proceso qué papel tiene.

Distinguir los tres resultados

pid_t rc = fork();
if (rc < 0) {
    perror("fork");
    exit(1);
} else if (rc == 0) {
    printf("child %ld\n", (long) getpid());
} else {
    printf("parent of %ld\n", (long) rc);
}

Usa <unistd.h> para fork y getpid, <stdio.h> para imprimir y <stdlib.h> para exit. Si la llamada tiene éxito, el padre recibe el PID positivo del hijo y el hijo recibe 0. Si falla, quien llama recibe -1, errno explica el error y no existe ningún hijo.

Si el PID del padre es 5000 y el del hijo es 5001, el padre imprime «parent of 5001» y el hijo imprime «child 5001». No se garantiza que ninguno de los dos se ejecute primero. getpid() devuelve el PID de quien realiza la llamada; getppid() devuelve el PID de su padre. El hijo no reinicia main ni repite las instrucciones anteriores a la bifurcación.

Seguir la memoria privada y la entrada/salida compartida

El padre y el hijo comienzan con el mismo contenido de memoria ordinaria en espacios de direcciones separados. Si x es 10 antes de la llamada y el hijo cambia su copia a 20, la copia del padre sigue siendo 10. Incluso la dirección impresa de x puede coincidir: esas direcciones virtuales iguales pertenecen a espacios de direcciones de procesos distintos.

La copia en escritura evita copiar todas las páginas de memoria de inmediato. El padre y el hijo comparten inicialmente páginas físicas protegidas contra escritura. Cuando uno escribe en una página privada, el núcleo prepara una copia privada antes de permitir la escritura. Esto conserva el comportamiento de memorias separadas y reduce el coste cuando un hijo llama pronto a exec.

Los descriptores de archivo se comportan de otra manera. Sus entradas copiadas hacen referencia a la misma descripción de archivo abierto subyacente, que incluye el desplazamiento actual dentro del archivo. Las lecturas secuenciales mediante un descriptor heredado hacen avanzar ese desplazamiento compartido. La tabla de descriptores se copia, pero el estado subyacente del archivo abierto en el núcleo puede seguir compartido.

Contar solo las bifurcaciones que alcanza un proceso

Si todas las llamadas tienen éxito, fork(); fork(); deja cuatro procesos: los dos procesos producidos por la primera llamada ejecutan la segunda. Un bucle de tres iteraciones que alcanzan todos los procesos deja $2^3=8$ procesos, incluido el original. Una bifurcación dentro de una rama exclusiva del padre la alcanzan menos procesos, por lo que la duplicación repetida ya no describe todo el programa.

Vaciar deliberadamente el texto almacenado en búfer

printf puede dejar texto en un búfer del espacio de usuario. fork copia ese búfer junto con el resto de la memoria. Si la salida se redirige a un flujo con almacenamiento completo en búfer, el texto impreso antes de la bifurcación puede ser vaciado por ambos procesos al terminar normalmente.

Para printf("start\n"); fork();, la terminal habitual, que almacena la salida por líneas, vacía el texto al encontrar el salto de línea antes de la bifurcación. Un archivo al que se redirige la salida puede retenerlo y recibir dos copias. fflush(stdout) antes de fork() envía el texto pendiente una sola vez. El duplicado procede de los datos copiados en el búfer, no de ejecutar dos veces el printf anterior.

Un proceso puede conservar su identidad mientras cambia el programa que ejecuta. La familia exec realiza esa sustitución. Combinarla con fork permite que un padre continúe su trabajo mientras un hijo pasa a ejecutar otro programa.

Sustituir la imagen y conservar el proceso

Una llamada a exec que tiene éxito sustituye el código, los datos estáticos, el montículo y la pila anteriores. El núcleo prepara los argumentos y el estado de entrada del nuevo programa y luego inicia su código de arranque. El lugar desde el que se hizo la llamada ya no existe, por lo que una llamada a exec que tiene éxito nunca retorna a él.

El PID, la relación con el padre y el directorio actual se conservan. Los descriptores abiertos se conservan, salvo los marcados para cierre al ejecutar exec. Las señales con un manejador instalado vuelven a su disposición predeterminada; las que se ignoran suelen seguir ignorándose. Las credenciales normalmente siguen siendo las mismas, pero los permisos set-user-ID o set-group-ID de un ejecutable pueden cambiar las credenciales efectivas cuando el sistema lo permite.

Construir un vector de argumentos válido

Para ejecutar wc -l notes.txt, el hijo puede usar:

char *args[] = {"wc", "-l", "notes.txt", NULL};
execvp(args[0], args);
perror("execvp");
_exit(127);

Las cadenas son argumentos separados, no una sola línea de comandos combinada. Por convenio, args[0] identifica el programa. El NULL final es un puntero que marca el final del array; no es la cadena «NULL». Sin un terminador válido, la llamada puede leer más allá del array.

Las líneas posteriores a execvp gestionan el fallo. Si no se encuentra el programa, exec devuelve -1 y establece errno, por ejemplo en ENOENT. Después, _exit termina el hijo sin vaciar los búferes de salida de C heredados. Volver al bucle del intérprete de comandos después del fallo crearía accidentalmente otra ruta de ejecución del intérprete.

Interpretar el nombre de la variante

La v de execv significa que los argumentos llegan como un vector; las variantes l reciben una lista. Una variante p busca un nombre de programa en PATH. Una variante e proporciona un entorno explícito. La llamada al sistema subyacente de Linux es execve; la biblioteca proporciona las variantes más cómodas de usar.

execvp("wc", args) busca en PATH. execv("wc", args) trata «wc» como una ruta relativa en el directorio actual. Se puede usar una ruta absoluta como /usr/bin/wc donde esté instalado ese ejecutable. Exec no interpreta la sintaxis del intérprete de comandos: una cadena > en args es solo un argumento, salvo que un programa la interprete por sí mismo.

Usar el intervalo previo a la sustitución

En el ejemplo con el padre de PID 6000 y el hijo de PID 6001, el hijo pasa a ejecutar wc, pero conserva el PID 6001. Su padre puede esperar a ese PID. Antes de exec, el hijo puede redirigir descriptores, conectar una tubería o cambiar de directorio; el programa que lo sustituye hereda el entorno preparado.

Esta separación es fundamental para el intérprete de comandos de Unix. CreateProcess de Windows combina la creación y la carga del programa, mediante parámetros que configuran el nuevo proceso. POSIX también ofrece posix_spawn para una operación combinada.

Un padre necesita saber si un hijo ha terminado y cómo lo ha hecho. La terminación del proceso y la recogida del resultado son pasos separados: el hijo termina y luego su padre recolecta el registro que queda en el núcleo.

Terminar un proceso

Retornar de main o llamar a exit(status) termina la ejecución normal. exit vacía los búferes de salida de C y ejecuta los manejadores de salida registrados. _exit(status) termina sin esa liberación de recursos de la biblioteca, lo que es útil después de un exec fallido en un hijo creado mediante fork. Por convenio, 0 indica éxito y un valor distinto de cero indica fallo.

Una señal también puede terminar un proceso. SIGTERM solicita la terminación y puede ser gestionada por un manejador; SIGKILL no se puede capturar ni ignorar. SIGSTOP detiene la ejecución y tampoco se puede capturar ni ignorar; SIGCONT reanuda un proceso detenido. Una terminal normalmente envía SIGINT por Ctrl-C y SIGTSTP por Ctrl-Z al trabajo en primer plano. Una señal es una notificación de software a un proceso, no una interrupción de hardware.

Esperar un resultado

wait(&status) espera a un hijo y devuelve su PID. waitpid(pid, &status, 0) selecciona un PID positivo de un hijo concreto. Un hijo que ha terminado y no ha sido recolectado puede recogerse inmediatamente. En caso contrario, una espera bloqueante normal suspende al padre hasta que haya un resultado disponible que cumpla el criterio.

Con WNOHANG, waitpid devuelve 0 cuando existen hijos que cumplen el criterio, pero ninguno tiene un resultado listo. Un resultado positivo identifica al hijo recogido. Un resultado de -1 indica un error: ECHILD significa que no queda ningún hijo que cumpla el criterio; EINTR significa que un manejador de señales interrumpió la espera.

Decodificar el estado antes de usarlo

int status;
pid_t r;
do {
    r = waitpid(child, &status, 0);
} while (r == -1 && errno == EINTR);
if (r == -1) {
    perror("waitpid");
} else if (WIFEXITED(status)) {
    printf("exit %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("signal %d\n", WTERMSIG(status));
}

Esto usa <sys/wait.h>, <errno.h> y <stdio.h>. El estado almacenado codifica tanto la forma de terminación como un resultado. WEXITSTATUS tiene sentido después de que WIFEXITED sea verdadero; WTERMSIG se usa después de WIFSIGNALED.

Solo están disponibles los ocho bits menos significativos de un valor de salida normal. Por tanto, exit(300) produce 44, mientras que exit(-1) produce 255. En Linux, exit(3) suele producir el estado devuelto por wait sin decodificar 768; imprimir ese entero no equivale a decodificar el código de salida.

Recolectar zombis y reconocer huérfanos

Un zombi ha terminado, pero conserva su PID y su resultado hasta que una espera los recoge. No ejecuta código, por lo que enviarle SIGKILL no puede eliminarlo. Un padre de larga duración debe recolectar a cada hijo. Para recoger a todos los hijos, sigue esperando después de cada PID positivo, vuelve a intentarlo ante EINTR y detente ante ECHILD; informa de los demás errores.

Un huérfano ha perdido a su padre y puede seguir ejecutándose. Linux le asigna como nuevo padre un proceso recolector de descendientes adecuado o el proceso init del espacio de nombres, que puede recoger su resultado más adelante. Los permisos normales para enviar señales dependen de las identidades y los privilegios de los usuarios. Ejecutarse como root concede permisos, no ejecución en modo núcleo.

Un intérprete de comandos convierte el texto de los comandos en creación de procesos, preparación de descriptores y recogida de resultados. Es un programa de usuario normal que usa los mismos servicios protegidos del SO disponibles para otros programas.

Iniciar un comando externo

Para wc -l notes.txt, el intérprete de comandos construye el vector de argumentos e inicia el comando. Las palabras analizadas forman un vector de argumentos terminado en un puntero nulo, args:

pid_t child = fork();
if (child == -1) {
    perror("fork");
} else if (child == 0) {
    execvp(args[0], args);
    perror("execvp");
    _exit(127);
} else {
    int status;
    pid_t result;
    do {
        result = waitpid(child, &status, 0);
    } while (result == -1 && errno == EINTR);
    if (result == -1) perror("waitpid");
    else if (WIFEXITED(status)) {
        printf("exit %d\n", WEXITSTATUS(status));
    } else if (WIFSIGNALED(status)) {
        printf("signal %d\n", WTERMSIG(status));
    }
}

Esto usa <unistd.h>, <sys/wait.h>, <errno.h> y <stdio.h>. El intérprete de comandos que contiene este código lee y analiza cada comando, sigue esta ruta de inicio y luego muestra su siguiente indicador de entrada.

Solo el hijo sustituye su programa; el intérprete puede recoger el fallo de un comando como resultado de terminación. Los comandos internos como cd deben cambiar el estado del propio intérprete: cambiar el directorio de un hijo dejaría al intérprete padre donde estaba.

Redirigir un descriptor antes de exec

Para ls -l > out.txt, el hijo abre el destino para escritura, creándolo o truncándolo. Luego hace que la salida estándar haga referencia a ese archivo:

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd == -1) { perror("open"); _exit(1); }
if (dup2(fd, STDOUT_FILENO) == -1) {
    perror("dup2"); _exit(1);
}
if (fd != STDOUT_FILENO && close(fd) == -1) {
    perror("close"); _exit(1);
}

open necesita <fcntl.h>; las llamadas a descriptores y _exit usan <unistd.h>. El modo de creación se filtra mediante la máscara de creación de archivos del proceso. La comprobación fd != STDOUT_FILENO mantiene abierto el descriptor 1 aunque open haya devuelto 1. Una vez completada la preparación, exec conserva el descriptor 1 y ls escribe normalmente sin conocer la redirección.

Un enfoque más antiguo cierra el descriptor 1 antes de abrir el archivo: open devuelve el descriptor libre más bajo. dup2 expresa el destino de forma explícita. La redirección de entrada conecta de forma similar un archivo legible al descriptor 0.

Conectar dos comandos

Para ls | wc -l, pipe(fds) crea un extremo de lectura fds[0] y un extremo de escritura fds[1]. El hijo productor conecta el extremo de escritura al descriptor 1. El hijo consumidor conecta el extremo de lectura al descriptor 0. Después de duplicarlos, cada uno cierra los descriptores originales de la tubería que no necesita. El padre cierra sus copias y espera a ambos hijos.

Crea ambos hijos antes de esperar a cualquiera de ellos. Un productor puede llenar la tubería y bloquearse; el lector debe existir para vaciarla. El lector solo alcanza el fin de archivo cuando se cierran todos los descriptores de escritura y se han consumido los datos almacenados en la tubería. Un extremo de escritura sin usar que el padre mantiene abierto puede hacer que wc espere indefinidamente.

Mantener disponible el indicador de entrada

Para sleep 60 &, el intérprete de comandos inicia el hijo y presenta el siguiente indicador sin esperar inmediatamente. Más tarde usa esperas no bloqueantes o responde a SIGCHLD para recolectar a los hijos terminados.

El estado de salida también controla las combinaciones de comandos. make && ./app inicia el segundo comando solo después de un resultado satisfactorio; make || echo failed inicia el segundo solo después de un fallo. Estas decisiones usan el resultado decodificado, no el estado codificado devuelto por wait sin decodificar.

El núcleo debe permitir que los programas calculen rápidamente y, al mismo tiempo, impedir operaciones que podrían tomar el control de la máquina. El modo de privilegio de la CPU es el límite de hardware que hace posibles ambas cosas.

Separar el cálculo del control privilegiado

En modo usuario, las instrucciones pueden acceder a la memoria permitida del proceso y realizar cálculos normales. No pueden cambiar libremente la configuración de hardware que protege a otros programas. En modo núcleo, también llamado modo supervisor o privilegiado, el SO puede realizar las operaciones protegidas necesarias para gestionar la máquina.

Las operaciones privilegiadas incluyen programar el temporizador, desactivar interrupciones, instalar manejadores de interrupciones, cambiar los registros de control de traducción de memoria, controlar directamente dispositivos protegidos y detener la CPU. Si cualquier aplicación pudiera desactivar el temporizador, los turnos cortos de CPU dependerían de la cooperación de esa aplicación.

AArch64 también proporciona EL2 para hipervisores y EL3 para firmware seguro. Estos nombres identifican niveles de privilegio del hardware, no distintos tipos de cuentas de usuario.

Entrar en una dirección controlada

El código de usuario no puede elevar su propio privilegio ni elegir cualquier dirección del núcleo para ejecutarla. La entrada se produce mediante una llamada al sistema, una excepción causada por una instrucción o una interrupción de hardware. La CPU transfiere el control a un punto de entrada configurado por el SO. El código de retorno del núcleo restaura el estado de usuario guardado y reduce el nivel de privilegio para reanudar el código de la aplicación.

El núcleo también protege sus datos mediante permisos de memoria. Un proceso puede tener direcciones del núcleo en su organización virtual y, aun así, carecer de permiso en modo usuario para acceder a ellas. Conocer una dirección no concede acceso a los bytes que contiene.

Considera una aplicación de Linux x86-64 que ejecuta hlt, una instrucción destinada a detener una CPU hasta que ocurra un evento. En modo usuario, la instrucción provoca una excepción. Linux normalmente envía SIGSEGV, cuya acción predeterminada termina ese proceso. La aplicación no detiene todo el computador; el límite de protección convierte el intento de operación privilegiada en un evento que gestiona el núcleo.

Separar la identidad del modo

Un proceso de root o administrador sigue siendo un programa en modo usuario mientras se ejecutan sus propias instrucciones. Su identidad de usuario le da un permiso más amplio para solicitar servicios. Sigue entrando en el núcleo mediante rutas controladas y el núcleo comprueba la solicitud.

Por ejemplo, una utilidad de mantenimiento privilegiada puede tener permiso para abrir un archivo protegido. La utilidad lo solicita mediante una llamada al sistema; no se convierte en código del núcleo solo porque se permita la solicitud. A la inversa, cuando el código del núcleo atiende una llamada a read de un usuario normal, se ejecuta en modo núcleo aunque quien llama no tenga una identidad administrativa.

En una CPU lógica, esto ocurre en secuencia: instrucciones de usuario, entrada en el núcleo, trabajo del núcleo y retorno a las instrucciones de usuario. No es una ejecución simultánea de un programa y una segunda tarea del SO en esa misma CPU. Distintas CPU lógicas pueden ejecutar distintos modos en el mismo instante.

Un programa en C a menudo parece llamar a una función normal cuando necesita un servicio del SO. Debajo de la función envoltorio de una llamada al sistema, una transición controlada de la CPU permite al código del núcleo validar y realizar esa solicitud.

Distinguir una llamada de biblioteca de una solicitud al núcleo

La biblioteca de C implementa strlen en espacio de usuario sin una llamada al sistema. printf da formato a los datos y puede almacenarlos en un búfer; una llamada posterior a write transfiere bytes a través del núcleo. Una función envoltorio sencilla de read prepara los argumentos según el convenio de llamadas al sistema de la plataforma y ejecuta la instrucción de entrada.

POSIX describe interfaces para sistemas de tipo Unix. Linux implementa muchos servicios agrupados de forma general en control de procesos, operaciones de archivos y dispositivos, información, comunicación y protección. Un número de llamada al sistema selecciona un servicio de la tabla de despacho del núcleo. Los números dependen de la plataforma: Linux x86-64 usa 1 para write y 39 para getpid; AArch64 usa 64 para write.

Seguir una solicitud de escritura

Para write(1, "hi\n", 3) en Linux x86-64, sigue la solicitud en orden:

1. La función envoltorio coloca el número de servicio 1 en rax, el descriptor 1 en rdi, la dirección del búfer en rsi y la cantidad 3 en rdx.
2. syscall conserva la dirección de retorno y los indicadores en registros, entra en modo núcleo y salta al punto de entrada configurado. No cambia de pila automáticamente.
3. El código de entrada del núcleo establece la pila del núcleo del proceso y guarda el resto del estado de usuario.
4. El despacho del núcleo selecciona write; la implementación comprueba el descriptor, el acceso al búfer de usuario y la solicitud antes de pasar los bytes hacia el recurso de salida.
5. Si se escriben todos los bytes correctamente, el resultado es 3 bytes. El código de retorno del núcleo restaura el estado de usuario y reanuda la función envoltorio, que retorna a quien la llamó.

El descriptor 1 puede identificar una terminal, un archivo o una tubería. El número por sí solo no identifica el dispositivo de salida. Una escritura también puede devolver una cantidad menor de bytes escritos sin que haya un error; quienes necesitan transferir todos los bytes llevan la cuenta de la cantidad realmente escrita.

Comprobar errores en la interfaz

El núcleo trata los punteros de usuario y los demás argumentos como no fiables. Una solicitud para copiar desde un búfer inaccesible puede fallar con EFAULT; la copia controlada evita conceder a quien llama acceso a la memoria del núcleo.

En Linux, un error del núcleo es un código de error negativo. La función envoltorio habitual de C devuelve -1 y establece errno. Por ejemplo, si open("missing.txt", O_RDONLY) falla porque el archivo no existe, errno es ENOENT. perror("missing.txt") puede mostrar «missing.txt: No such file or directory». Consulta errno después de que se indique un fallo, no como comprobación principal de éxito: una llamada que tiene éxito no tiene por qué borrar un error anterior.

Tener en cuenta el tiempo empleado en el núcleo

Una llamada que puede terminar en ese momento puede retornar al mismo proceso. Una lectura bloqueante de terminal puede, en cambio, poner ese proceso en estado bloqueado y dejar que otro se ejecute. El evento de entrada hace que el lector quede listo; una vez planificado, completa la ruta de retorno.

La entrada en el núcleo añade trabajo respecto de una llamada normal a una función: guardar el estado, cambiar de privilegio, comprobar los argumentos y restaurar la ejecución. El almacenamiento en búfer de la biblioteca puede combinar salidas pequeñas en menos escrituras. En Linux, strace ls ejecuta ls mientras informa de sus llamadas al sistema, argumentos y resultados.

La entrada en el núcleo puede deberse a una solicitud de servicio, un problema de instrucción o un evento de dispositivo. Clasificar la causa te ayuda a predecir qué hará el SO y si debe volver a ejecutarse la misma instrucción.

Preguntar qué causó el evento

Síncrono significa que está ligado a la instrucción que se ejecuta. No significa que la misma entrada cause exactamente los mismos fallos en cada ejecución. Una carga puede fallar cuando su página está ausente y tener éxito más tarde cuando esa página está presente en memoria. Asíncrono significa que la causa del evento es independiente de la instrucción actual, como cuando un disco completa un trabajo anterior.

Los manuales de CPU usan estos términos de distintas maneras. Sigue la causa: solicitud deliberada de servicio, evento causado por una instrucción o notificación de hardware.

Despachar al manejador correcto

Durante el arranque, el SO instala direcciones protegidas de manejadores. Una tabla de trampas o interrupciones asigna los tipos de eventos a rutinas del núcleo. En x86-64, la tabla de descriptores de interrupción (IDT) atiende las interrupciones y excepciones; syscall usa una dirección de entrada en un registro especial del procesador. Solo el código privilegiado puede configurar estos destinos.

Ante una interrupción desde el modo usuario, el hardware x86-64 guarda un marco de retorno en una pila del núcleo. El código de entrada guarda registros adicionales antes de realizar el trabajo. La ruta de syscall conserva su estado inicial de retorno en registros y depende del código de entrada para establecer la pila del núcleo. Tratar todas las rutas de entrada como acciones de hardware idénticas oculta una diferencia importante de implementación.

Elegir el resultado

Se puede cargar una página válida que no está en memoria, tras lo cual se vuelve a intentar la instrucción que provocó el fallo. Un acceso a memoria que el proceso no puede usar normalmente hace que Linux envíe SIGSEGV. Por tanto, una excepción no siempre es fatal ni siempre implica saltarse la instrucción actual.

Para una instrucción entera real idiv de x86-64 con divisor cero, la CPU genera una excepción de error de división. Linux normalmente entrega SIGFPE; su conocido mensaje menciona el punto flotante incluso para esta instrucción entera. En cambio, la división entera de AArch64 da cero cuando el divisor es cero. La división entre cero en C tiene un comportamiento indefinido, por lo que el código C portable no puede depender de ninguno de los dos resultados de la máquina.

Cuando termina una lectura de disco, el manejador de interrupciones registra su finalización y pasa el proceso que espera a listo. Ese proceso puede ejecutarse más tarde. Una interrupción del temporizador da al SO la oportunidad de reconsiderar qué proceso usa actualmente la CPU, pero el manejador también puede volver a ese mismo proceso.

Distinguir una señal de una interrupción

Una interrupción de hardware notifica a la CPU; una señal notifica a un proceso a través del SO. Una excepción puede hacer que el núcleo envíe una señal, y un proceso puede solicitar una señal para otro mediante kill. Las finalizaciones normales de dispositivos son interrupciones que no implican errores de programa.

El código del núcleo también debe proteger los datos compartidos mientras ocurren eventos. Puede desactivar brevemente las interrupciones en una CPU y usar cerrojos donde sea necesario. Los periodos largos con interrupciones desactivadas retrasan la atención a los dispositivos; desactivar solo las interrupciones locales no impide que otra CPU acceda a los datos compartidos.

Ejecutar cada instrucción de una aplicación en un simulador de software haría costosa la compartición de la CPU. Permitir que una aplicación controle la máquina sin límites haría insegura esa compartición. La ejecución directa limitada (LDE) usa la ejecución normal en el hardware con una ruta protegida de regreso al SO.

Resolver dos problemas de control distintos

La ejecución directa significa que las instrucciones normales de un proceso se ejecutan en la propia CPU. El SO no examina ni aprueba cada instrucción aritmética. Quedan dos problemas: restringir las operaciones que podrían dañar la máquina y recuperar el control cuando un programa no se detiene voluntariamente.

El modo usuario resuelve el problema de las restricciones. Las trampas de llamadas al sistema permiten que un programa solicite servicios sin elegir código privilegiado arbitrario. Un temporizador de hardware resuelve el problema del control: puede interrumpir una aplicación que no realiza ninguna llamada. Juntos, estos mecanismos permiten virtualizar la CPU con poca sobrecarga.

Preparar el sistema antes de ejecutar aplicaciones

Durante el arranque, el núcleo configura los manejadores de eventos e inicializa el temporizador. Estas operaciones de configuración son privilegiadas. Los programas de usuario posteriores no pueden redirigir los manejadores ni desactivar el temporizador para evitar perder sus turnos.

Para iniciar un proceso, el SO crea su registro de gestión y su imagen de memoria, prepara los argumentos de arranque y una pila de usuario, y establece los valores iniciales de los registros. Prepara un contexto inicial guardado para que la ruta normal de retorno del núcleo al usuario pueda iniciar el programa. Conceptualmente, el proceso comienza retornando de una trampa que nunca realizó.

La organización detallada del marco guardado depende de la CPU y del SO. La idea de diseño útil es la reutilización: el mismo mecanismo de restauración puede reanudar un proceso suspendido o iniciar uno recién preparado.

Volver al núcleo voluntariamente

Durante una llamada al sistema, el hardware conserva el estado inicial de retorno y transfiere el control. El código de entrada del núcleo guarda los registros adicionales en la pila del núcleo del proceso. Después de completar una solicitud no bloqueante, el núcleo restaura el proceso y vuelve al modo usuario. Si la solicitud bloquea el proceso, primero puede ejecutarse otro proceso listo.

Cuando main retorna, el procesamiento de salida del entorno de ejecución acaba pidiendo al núcleo que termine el proceso. Su memoria puede liberarse mientras su registro de terminación permanece hasta que un padre lo recolecte.

Volver sin cooperación

Un sistema cooperativo depende de que los programas realicen llamadas, cedan la CPU o provoquen excepciones. Un bucle infinito que no hace ninguna de estas cosas puede monopolizar una CPU. El Mac OS clásico ilustra esta debilidad.

Un diseño no cooperativo usa una interrupción del temporizador para forzar la entrada en el núcleo. Considera un modelo didáctico con una CPU lógica y un temporizador periódico cada 4 ms. El temporizador produce 1000 / 4 = 250 pulsos por segundo. Un proceso de usuario atrapado en while (1) { } es interrumpido en el siguiente pulso. El núcleo puede entonces ejecutar otro proceso listo; el bucle no necesita alcanzar primero una llamada al sistema.

El pulso es una oportunidad para actuar, no una obligación de cambiar de proceso. El planificador puede dejar que continúe el proceso interrumpido. La gestión del temporizador y la restauración del estado guardado son mecanismos; la elección del planificador es una política. El tiempo de respuesta real también depende del trabajo del núcleo y de cuándo pueden gestionarse las interrupciones, por lo que el periodo del temporizador por sí solo no garantiza el tiempo de respuesta de una aplicación.

Entrar en modo núcleo no cambia necesariamente el proceso en ejecución. Un cambio de contexto ocurre cuando el núcleo conserva el estado de ejecución de un proceso y reanuda el de otro. Esto requiere tanto conservar el estado de usuario como cambiar el propio contexto de ejecución del núcleo.

Seguir la salida de A y la entrada de B

Para un cambio provocado por el temporizador en x86-64, sigue las capas:

1. A ejecuta instrucciones de usuario. El temporizador lo interrumpe.
2. El hardware pasa a modo núcleo y guarda el marco de retorno de interrupción de A en la pila del núcleo de A. El código de entrada guarda allí los demás registros de usuario de A.
3. El planificador elige B. La rutina de cambio guarda el contexto de ejecución del núcleo de A y restaura el contexto del núcleo guardado de B, incluido su puntero de pila del núcleo.
4. El núcleo cambia al contexto del espacio de direcciones de B según sea necesario. Ahora se ejecuta en nombre de B usando la pila del núcleo de B.
5. El código de salida del núcleo restaura los registros de usuario de B. La instrucción de retorno restaura el estado de retorno de B y entra en modo usuario. B se reanuda donde se detuvo anteriormente.

El primer guardado conserva la ejecución de usuario interrumpida de A. El segundo conserva el punto en el que estaba el núcleo mientras atendía a A. No son dos copias completas e idénticas del mismo conjunto de registros. Un PCB o estructura de contexto asociada y la pila del núcleo de cada proceso trabajan conjuntamente para conservar el estado.

Identificar el evento y la decisión

Una llamada bloqueante, la terminación de un proceso o una decisión tras una interrupción del temporizador pueden provocar un cambio. Una interrupción de dispositivo puede hacer que otro proceso quede listo y la planificación puede seleccionarlo entonces. Todo el mecanismo de cambio se ejecuta en el núcleo; una aplicación no guarda sus propios registros para ofrecerse a ser interrumpida.

Un cambio de contexto conserva el estado de ejecución necesario para continuar. El tiempo transcurre y el mundo exterior puede cambiar: los desplazamientos compartidos de archivos y las entradas externas no quedan congelados mientras un proceso está en pausa.

Tener en cuenta los costes directos e indirectos

El trabajo directo incluye ejecutar el planificador, guardar y restaurar registros y seleccionar un espacio de direcciones. Las cachés de traducción pueden necesitar ajustes; las traducciones etiquetadas pueden evitar que se descarten todas las entradas anteriores. Después aparecen costes indirectos cuando B debe volver a llenar las cachés de la CPU o las traducciones de direcciones almacenadas en caché que A desplazó. El coste depende del hardware y de la carga de trabajo, así que usa valores medidos o indicados al calcular la sobrecarga.

Supón que un cambio, incluidos sus efectos pertinentes, cuesta 5 µs y que los turnos útiles de CPU duran 10 ms. Convierte 10 ms en 10 000 µs. La proporción dedicada al cambio es 5 / (10 000 + 5), aproximadamente 0,05 %. Para turnos útiles de 1 ms es 5 / 1005, aproximadamente 0,50 %; con 0,1 ms es 5 / 105, aproximadamente 4,8 %.

El denominador incluye el trabajo útil más el tiempo de cambio de un ciclo repetido. Un turno más corto puede mejorar las oportunidades para el trabajo interactivo, pero dedica una fracción mayor a cambios repetidos. El temporizador y el código de cambio hacen posibles los turnos cortos; la política de planificación debe sopesar ese coste frente a la rapidez de respuesta.