Fundamentos de sistemas operativos
El sistema operativo es el que reparte el procesador, la memoria y los periféricos entre programas que se creen dueños de la máquina. Entender cómo lo hace explica casi todos los comportamientos raros de un programa.
01El que reparte la máquina
Un programa se escribe como si fuera dueño del procesador, de la memoria y de los periféricos. No lo es: hay decenas corriendo a la vez. El sistema operativo mantiene esa ilusión y reparte lo que hay.
| Recurso | Lo que ve el programa | Lo que hay de verdad |
|---|---|---|
| Procesador | Uno para él solo | Unos pocos núcleos repartidos en tajadas de milisegundos |
| Memoria | Un espacio continuo desde la dirección cero | Páginas dispersas en RAM, y parte en disco |
| Disco | Archivos y carpetas | Bloques numerados en un dispositivo |
| Periféricos | Un archivo que se abre y se lee | Registros de hardware e interrupciones |
Para sostener esa ilusión el procesador tiene dos modos: el de usuario, donde corren los
programas y ciertas instrucciones están prohibidas, y el de núcleo, donde corre el sistema operativo. Se
pasa de uno al otro por una llamada al sistema, que es una interrupción deliberada. Cada
open, read o write cruza esa frontera, y por eso cuestan mucho más
que una función común.
02Procesos e hilos
| Proceso | Hilo | |
|---|---|---|
| Memoria | La suya, aislada | Comparte la del proceso |
| Crear uno cuesta | Bastante | Poco |
| Si falla | Se muere él solo | Se lleva puesto todo el proceso |
| Comunicarse | Por tuberías, sockets, memoria compartida | Variables comunes, con cuidado |
Cada proceso pasa por unos pocos estados: listo cuando puede correr, ejecutando cuando tiene el procesador, y bloqueado cuando espera algo —un dato del disco, un byte del puerto serie—. Esa tercera es la clave: un proceso bloqueado no gasta procesador, y por eso una máquina puede tener cientos de programas abiertos sin transpirar.
03Planificación
Cuando hay más procesos listos que núcleos, alguien decide quién sigue. Esa política es el planificador, y de ella dependen dos números que se contradicen: el tiempo de retorno —cuánto tarda un trabajo de punta a punta— y la respuesta, que es lo que percibe quien está sentado frente a la máquina.
Los mismos cuatro procesos, repartidos con distintas políticas. Mirá el diagrama y comparé los promedios.
Cada vez que el planificador cambia de proceso hay que guardar todos los registros del que sale y cargar los del que entra: unos microsegundos, más el costo invisible de que la caché quede llena de datos ajenos. Con quantum muy chico la máquina se pasa el día cambiando de contexto en lugar de trabajar; con quantum muy grande, se pierde la respuesta interactiva.
04Memoria virtual
Cada proceso ve direcciones que no son las de la RAM. La unidad de gestión de memoria del procesador traduce cada dirección virtual a una física consultando una tabla de páginas, y de ahí salen tres cosas valiosas:
- Aislamiento. Un proceso no puede tocar la memoria de otro, porque su tabla ni siquiera la nombra. Esa es la razón de que un programa que se cuelga no arrastre a la máquina entera.
- Memoria más grande que la RAM. Las páginas que no se usan bajan al disco. Si el programa vuelve a tocarlas, se produce un fallo de página y el sistema las trae de vuelta.
- Compartir sin copiar. Dos procesos que usan la misma biblioteca apuntan a las mismas páginas físicas.
Si los programas piden más memoria activa de la que hay, el sistema pasa el tiempo subiendo y bajando páginas: es la hiperpaginación. La máquina parece muerta pero el procesador está casi ocioso; lo que está saturado es el disco. Se reconoce enseguida porque el indicador de actividad de disco no para.
05Concurrencia
Dos hilos que tocan la misma variable sin coordinarse producen el error más difícil de encontrar de
toda la programación. contador++ no es una operación atómica: son tres —leer, sumar,
guardar— y entre ellas el planificador puede cambiar de hilo.
| Herramienta | Para qué |
|---|---|
| Exclusión mutua (mutex) | Que sólo un hilo por vez entre a la sección crítica |
| Semáforo | Contar recursos disponibles; sincronizar productor y consumidor |
| Variable de condición | Esperar a que algo pase, sin consumir procesador |
| Operaciones atómicas | Un contador compartido, sin bloquear |
| Cola entre hilos | La forma más segura: nadie comparte estado, se pasan mensajes |
Dos hilos, cada uno con un candado, esperando el del otro: ninguno avanza nunca. Hacen falta cuatro condiciones a la vez, y basta romper una para evitarlo. La regla práctica es tomar siempre los candados en el mismo orden en todo el programa.
06Qué cambia en tiempo real
Un sistema operativo común busca que todo ande rápido en promedio. Uno de tiempo real busca algo distinto: que una respuesta ocurra siempre antes de un plazo. Un promedio excelente con un caso peor impredecible no sirve para controlar un motor.
| Propósito general | Tiempo real | |
|---|---|---|
| Objetivo | Buen promedio | Caso peor acotado |
| Planificación | Equidad y respuesta | Por prioridad, con expropiación |
| Latencia de interrupción | Variable | Garantizada, de microsegundos |
| Ejemplos | Linux, Windows | FreeRTOS, Zephyr, QNX |
En un microcontrolador, un sistema como FreeRTOS aporta tareas con prioridad, colas y semáforos en unos pocos kilobytes. La inversión de prioridad —una tarea de baja prioridad que retiene un candado que necesita una de alta— es el problema clásico, y se resuelve con herencia de prioridad.
07En el laboratorio
Con top o el administrador de tareas, observar estados, memoria y uso de procesador.
Lanzar un bucle infinito y ver qué cambia; después uno que sólo espere entrada y comparar.
Dos hilos que incrementan un contador común un millón de veces cada uno. Verificar que el resultado no es dos millones, y después arreglarlo con un mutex.
Una tarea que parpadea un LED cada 500 ms y otra que lee el puerto serie, comunicadas por una cola. Medir con un osciloscopio si el parpadeo se corre cuando llegan datos: eso es la latencia.
08Errores frecuentes
- Creer que
contador++es atómico. - Tomar candados en distinto orden en partes distintas del programa: interbloqueo asegurado.
- Esperar con un bucle vacío en lugar de bloquearse: gasta un núcleo entero sin hacer nada.
- Suponer que más hilos es más rápido. Si el trabajo es de disco o de red, no lo es.
- Confundir concurrencia con paralelismo. Concurrente es que avanzan de a ratos; paralelo, que corren a la vez en núcleos distintos.
- Usar un sistema común donde hace falta uno de tiempo real, y descubrirlo en el campo.
09Autoevaluación
¿Qué diferencia hay entre un proceso y un hilo?
El proceso tiene su memoria aislada; los hilos de un proceso la comparten. Crear un hilo cuesta mucho menos, pero si uno rompe la memoria se lleva a todos.
¿Por qué una llamada al sistema cuesta más que una función común?
Porque cruza del modo usuario al modo núcleo: hay que cambiar de contexto, validar parámetros y volver.
¿Qué pasa con un quantum demasiado chico en Round-Robin?
El sistema gasta más tiempo cambiando de contexto que ejecutando: el trabajo útil baja aunque la respuesta parezca buena.
¿Qué es un fallo de página?
El acceso a una página que no está en RAM. El sistema la trae del disco y reanuda el proceso, que no se entera de nada salvo por la demora.
¿Cómo se evita un interbloqueo en la práctica?
Tomando siempre los candados en el mismo orden en todo el programa, y usando tiempos de espera al intentar tomarlos.
¿Qué garantiza un sistema operativo de tiempo real que no garantiza Linux?
Un caso peor acotado: la respuesta ocurre siempre antes del plazo, no sólo en promedio.
10Para ampliar
- Abraham Silberschatz, Peter Galvin y Greg Gagne. Fundamentos de sistemas operativos. 10.ª ed., Wiley, 2018. El texto clásico de la materia: procesos, planificación, memoria y concurrencia.
- Remzi y Andrea Arpaci-Dusseau. Operating Systems: Three Easy Pieces. Arpaci-Dusseau Books. Gratuito en línea. Explica virtualización, concurrencia y persistencia mejor que ningún otro, y es libre.
- Andrew S. Tanenbaum. Sistemas operativos modernos. 4.ª ed., Pearson, 2014. Riguroso y completo, con buenos capítulos de sistemas embebidos.
- Documentación de FreeRTOS. Mastering the FreeRTOS Real Time Kernel. Real Time Engineers Ltd. El tiempo real aplicado al microcontrolador, con ejemplos que se pueden correr.