Sistemas Operativos // Teoría

1.1 ¿Qué es y dónde vive el SO?

Una computadora moderna es un sistema complejo: integra muchos componentes físicos (CPU, memoria, discos, periféricos) y lógicos (programas). Nadie quiere hablarle directamente al hardware en cada aplicación. El sistema operativo se mete justo en el medio como intermediario entre el hardware de la máquina y el resto del software.

Hacé clic en cada capa para ver su rol:

1.2 Modo Kernel vs Modo Usuario

El hardware ofrece dos modos de ejecución. Esta separación es la base de la protección: sin ella, cualquier programa podría romper todo.

• Modo Kernel (Supervisor): el SO tiene acceso completo y privilegiado al hardware. Puede ejecutar cualquier instrucción que soporte el equipo.
• Modo Usuario: el resto del software corre con restricciones. Solo puede hacer operaciones permitidas y limitadas; si necesita algo privilegiado, le tiene que pedir al SO (vía llamada al sistema, lo vemos más abajo).

Probá ejecutar instrucciones en cada modo:

1.3 Tres definiciones de "Sistema Operativo"

No hay una sola definición canónica. La cátedra junta tres autores. Dale vuelta a cada tarjeta:

Las tres apuntan a lo mismo desde ángulos distintos: interfaz, coordinación y abstracción+administración.

1.4 Las dos perspectivas de Tanenbaum

Tanenbaum dice que el SO se puede mirar de dos formas, y las dos son ciertas a la vez:

¿Cómo reparte? → Multiplexado

Para administrar recursos, el SO usa multiplexado (compartir un recurso entre varios). Hay dos sabores:

1.5 Historia de los SO — Generaciones

⚠️ Ojo Tomi: vos mismo anotaste que la cátedra puede tomar fechas y nombres. Por eso los dejé todos. Hacé clic en cada generación para repasarlas.

1.6 Repaso del hardware (Unidad 1, parte 2)

El SO está pegado al hardware: extiende sus instrucciones y gestiona sus recursos. Conviene recordar las piezas básicas.

Procesadores — el ciclo de la CPU

La CPU ejecuta instrucciones en ciclos continuos. Modernamente usa canalización (pipelining) para tener varias instrucciones en vuelo a la vez. El ciclo básico:

Memoria — jerarquía por velocidad/capacidad/costo

La memoria se organiza en jerarquías: arriba lo más rápido, chico y caro; abajo lo más lento, grande y barato. Tocá un nivel:

Discos, cintas, E/S y buses

Los discos dan acceso más lento que la RAM pero son económicos y grandes; las cintas magnéticas sirven de respaldo para grandes volúmenes. Los dispositivos de E/S tienen controladores y se comunican por buses que transfieren datos entre componentes.

Arranque (boot): BIOS → MBR → SO

Al prender la máquina, el BIOS verifica el hardware básico y decide desde dónde arrancar, probando una lista de dispositivos guardada en la memoria CMOS. Luego carga el MBR y de ahí salta a la partición donde vive el SO.

1.7 Tipos de Sistemas Operativos

Según el tipo de máquina y propósito, los SO se especializan:

1.8 Conceptos clave que maneja el SO

El SO trabaja con un puñado de abstracciones centrales. Acá las presentamos rápido; algunas (procesos, memoria, archivos) tienen unidades enteras dedicadas más adelante.

El Shell

El shell es el intermediario entre el usuario y el SO: traduce comandos a llamadas al sistema. Ejemplos: sh, csh, ksh, bash. No es parte del kernel: es un programa de usuario más.

Llamadas al sistema (system calls)

Son la interfaz entre los programas y el SO: la forma "oficial" en que un programa de modo usuario le pide al kernel que haga algo privilegiado. Algunas:

1.9 Estructuras de los Sistemas Operativos

¿Cómo se organiza el SO por dentro? Hay varias arquitecturas:

// (En tu apunte MINIX 3 viene con un cariñoso comentario hacia Tanenbaum. Lo dejamos a tu imaginación.)

1.10 Clasificación de los SO

Cuatro ejes para clasificar cualquier SO:

2.1 Concepto y modelo de proceso

Un proceso es un programa en ejecución. Es la abstracción clave sobre la que se apoya todo el SO. Permite la ejecución pseudo-concurrente: la CPU conmuta rápidamente entre procesos (esto se llama multiprogramación), dando la ilusión de que todos corren a la vez.

Cada proceso es una instancia independiente de un programa, con su propio contador de programa, registros y variables. Aunque cada uno simula tener su CPU virtual propia, la CPU física en realidad salta entre ellos:

2.2 Creación de procesos

Hay cuatro eventos que disparan la creación de un proceso:

UNIX vs Windows

// Nota de tu apunte: "CreateProcess //no existe realmente" — guiño a que en Win32 hay un montón de variantes y wrappers. En ambos sistemas, tras crearse, los procesos tienen espacios de direcciones independientes, aunque pueden compartir ciertos recursos.

2.3 Terminación y jerarquías de procesos

Cuatro razones para terminar

1. Salida normal: completó su tarea.
2. Salida por error: encontró un error que sí puede manejar (sale a propósito).
3. Error fatal: error grave, como acceso inválido a memoria.
4. Eliminado por otro proceso: alguien lo mata (kill en UNIX, TerminateProcess en Windows).

Jerarquías

Algunos SO mantienen una jerarquía clara: UNIX organiza los procesos en un árbol, con init como raíz. Windows no mantiene jerarquías estrictas, lo que da una administración más flexible.

2.4 Estados y transiciones de un proceso

Acá hay dos modelos que la cátedra distingue. Cambiá de pestaña y hacé clic en los botones para mover el proceso entre estados.

2.5 Implementación: la tabla de procesos

El SO mantiene una tabla de procesos: una entrada por proceso (a veces llamada PCB, Process Control Block) con toda la info crítica para suspender y reanudar. Incluye:

Gracias a esta tabla, cuando la CPU vuelve a un proceso suspendido puede retomarlo exactamente donde lo dejó.

2.6 Hilos (threads)

Un proceso puede tener varios hilos: múltiples secuencias de ejecución dentro del mismo espacio de direcciones. Ventajas: facilitan tareas concurrentes, mejoran la eficiencia en operaciones de E/S y permiten aprovechar sistemas multiprocesador.

2.7 Planificación (Clase 5)

La planificación decide qué proceso o hilo se ejecuta cuando varios compiten por la CPU. La hace el planificador con algoritmos que buscan optimizar rendimiento y equidad. Históricamente era simple (sistemas batch), pero la multiprogramación y los sistemas interactivos la complicaron.

Comportamiento de un proceso: CPU-bound vs IO-bound

Los procesos alternan ráfagas de cálculo con esperas por E/S:

¿Cuándo planificar?

• Se crea un nuevo proceso.
• Un proceso termina.
• Un proceso se bloquea por E/S u otra razón.
• Se produce una interrupción que requiere atención.

Apropiativos vs No apropiativos

Tres categorías de algoritmos (y sus metas)

2.8 🎮 Simulador de algoritmos de planificación

Acá está lo bueno. Elegí un algoritmo, editá los tiempos de llegada y de ráfaga de cada proceso, y mirá cómo cambia el diagrama de Gantt y las métricas (tiempo de retorno y de espera promedio).

2.9 El resto del catálogo de algoritmos

En sistemas de procesamiento por lotes

• FCFS (First-Come First-Served): se atienden en orden de llegada.
• SJF (Shortest Job First): prioriza los cortos, minimizando el tiempo promedio.
• SRTN (Shortest Remaining Time Next): versión apropiativa de SJF, mira el tiempo restante.

En sistemas interactivos

En tiempo real

Es crucial respetar los plazos (deadlines). Hay dos tipos:

Política vs Mecanismo

Planificación de hilos

2.10 Concurrencia, exclusión mutua y sincronización (Clase 6)

Tres formas de gestionar múltiples procesos:

La concurrencia aparece en 3 contextos: múltiples aplicaciones, aplicaciones estructuradas (divididas en procesos/hilos) y en la propia estructura del SO.

Los 6 términos clave

Dales vuelta — son las palabras que más caen en el parcial:

Dificultades en mono y multiprocesador

1. Compartir recursos globales es un peligro.
2. Al SO le es complicado asignar recursos de forma óptima.
3. Es difícil localizar errores: los resultados son no deterministas y no reproducibles (¡condición de carrera!).

Las 4 preocupaciones del SO

1. Seguir la pista de los varios procesos (tabla de procesos).
2. Asignar y desasignar recursos: CPU, memoria (virtual), ficheros y dispositivos de E/S.
3. Proteger datos y recursos de cada proceso frente a interferencias de otros.
4. Que el resultado de un proceso sea independiente de la velocidad a la que corre respecto a los demás.

2.11 🏁 Demo: condición de carrera

Dos hilos quieren incrementar el mismo contador. Cada incremento son en realidad 3 micro-pasos: leer → sumar 1 → escribir. Si el SO entrelaza mal los pasos, se pierde un incremento. Probá las dos ejecuciones:

Resultado esperado: 2. Pero si ambos leen antes de que cualquiera escriba, los dos escriben "1" y se pierde un incremento. Eso es una condición de carrera, y se arregla con exclusión mutua.

2.12 Interacción de procesos y exclusión mutua

Tres niveles de interacción

Los tres males de la competencia

Cooperación entre procesos

Los 6 requisitos para la exclusión mutua

1. Un único proceso a la vez dentro de su sección crítica.
2. Un proceso detenido en su sección no crítica no debe interferir con otros.
3. No se puede postergar indefinidamente el acceso de un proceso a su zona crítica.
4. Si nadie está en su sección crítica, cualquiera debe poder entrar sin demora.
5. No se hacen suposiciones sobre las velocidades relativas de los procesos.
6. Un proceso permanece en la sección crítica solo un tiempo finito.

Soporte por hardware

El hardware ayuda con: deshabilitar interrupciones e instrucciones máquina atómicas como Test-and-Set o Exchange. Mantienen acceso atómico, pero tienen 3 desventajas:

2.13 🚦 Semáforos (Dijkstra, 1965)

Un semáforo es una variable que sincroniza procesos con dos operaciones atómicas: semWait(s) y semSignal(s). Permiten frenar procesos en un punto hasta recibir una señal. Es la herramienta estrella para exclusión mutua.

Probalo con un semáforo inicializado en 1 (es un mutex, deja entrar de a uno). Mandá procesos a pedir la sección crítica:

2.14 Monitores y paso de mensajes

Monitores

Los monitores los incorpora el lenguaje de programación. Encapsulan la exclusión mutua con procedimientos y datos locales, asegurando que solo un proceso acceda al recurso protegido a la vez. Simplifican mucho la programación concurrente al ofrecer estructuras claras. Se comunican con send(destino, mensaje) y receive(origen, mensaje).

Paso de mensajes

Permite a los procesos sincronizarse y comunicarse enviando/recibiendo mensajes. Tres ejes de diseño:

Exclusión mutua con paso de mensajes