Sistemas Operativos

Sesión 3: Arquitectura de hardware e interrupciones

Unidad 1 (Procesos) – Fundamentos técnicos (Arquitectura, interrupciones)

I.U. Pascual Bravo | Curso: Sistemas Operativos (ET0122) | Nivel 3

Alineación con planeación: “Arquitecturas de hardware Neuman–Harvard” e “Interrupciones, excepciones, llamadas”.

Qué haremos hoy

0–10 min: Calentamiento (modelo mental de “eventos”).
10–65 min: Arquitecturas + protección + tipos de eventos.
65–105 min: Práctica guiada (observación de actividad del sistema).
105–120 min: Exit ticket + conexión con sesión 4.

Objetivo de salida: distinguir interrupción vs excepción vs system call, y explicar por qué el timer es clave para el control del CPU.

La pregunta de hoy

Si el teclado, el disco o la red “terminan algo”, ¿cómo se entera el kernel sin que la CPU esté preguntando todo el tiempo?

Hoy vamos a construir el modelo: arquitectura + protección + eventos (interrupciones/excepciones/system calls).

Capas: hardware → kernel → aplicaciones

Hardware: CPU, RAM, controladores, dispositivos.
Kernel: coordina, protege, decide.
Apps: piden servicios; no controlan hardware directo.

Regla de oro: acceso a recursos críticos pasa por el kernel.

Von Neumann: un camino compartido

Instrucciones y datos comparten memoria/camino, lo cual simplifica pero crea competencia por el acceso.

Imagen: “Von Neumann architecture.svg” (Wikimedia Commons). Licencia: CC BY-SA 3.0 (también GFDL). Fuente: https://commons.wikimedia.org/wiki/File:Von_Neumann_architecture.svg

Pregunta guía: ¿qué pasa si CPU y dispositivo quieren el “mismo camino” al tiempo?

Harvard: caminos separados

Separación entre memoria de instrucciones y memoria de datos.
Útil en contextos donde importa rendimiento y control (común en embebidos).

Idea: menos interferencia entre “traer instrucciones” y “leer/escribir datos”.

Imagen: “Harvard Architecture.png” (Wikimedia Commons). Licencia: CC0 1.0 (dominio público por dedicación). Fuente: https://commons.wikimedia.org/wiki/File:Harvard_Architecture.png

Modo usuario vs modo kernel

Usuario: apps con permisos limitados.

Kernel: código privilegiado que puede controlar hardware.

¿Por qué? Para que un programa con error no pueda tumbar todo el sistema.

User mode:
  - No instrucciones privilegiadas
  - Memoria restringida

Kernel mode:
  - Maneja interrupciones
  - Controla dispositivos
  - Administra memoria y CPU

Interrupción vs Excepción vs System call

Interrupción: evento externo (dispositivo, timer).

Excepción: evento interno (error/condición en CPU).

System call: pedido voluntario de servicio al kernel.

Ejemplos:
- Interrupción: llega paquete de red
- Excepción: división por cero
- System call: abrir archivo, crear proceso

Qué sucede cuando llega una interrupción

La CPU detecta la señal.
Guarda contexto mínimo (para volver).
Salta al handler (rutina) del kernel.
Se atiende el evento (leer buffer, confirmar E/S, etc.).
Se restaura contexto y se retoma la ejecución.

Regla práctica: handler “rápido y pequeño” para no degradar todo el sistema.

El latido del sistema

El timer genera interrupciones periódicas; esto permite que el kernel recupere control y aplique políticas (p. ej., repartir CPU).

Cada tick:
  - Actualizar tiempo
  - Revisar quantum
  - Posible cambio de proceso (context switch)

Conexión con Sesión 4: scheduling moderno depende del timer.

Mapa de actividad del sistema

Objetivo: ver evidencia de que el sistema opera por eventos y actividad de I/O.

Si tienes Linux (PC o VM):

cat /proc/interrupts
watch -n 1 cat /proc/interrupts

Observa qué líneas crecen “solas” (timer) y cuáles cambian al interactuar (teclado/mouse/red).

Si tienes Windows:

Ctrl+Shift+Esc  (Task Manager)
resmon.exe      (Monitor de recursos)
Ver actividad en vivo: CPU y Disco

El foco es observar actividad del sistema cuando haces acciones (abrir apps, copiar archivos).

Hoja de trabajo (1 página)

¿Qué evento/actividad fue más frecuente en tu observación?
Describe 2 acciones que generaron cambios visibles.
Explica: ¿por qué el SO necesita interrupciones?
Da un ejemplo de: interrupción, excepción y system call.
Conexión: ¿cómo crees que esto ayuda a “repartir CPU”?

Exit ticket (10–12 min)

Individual, sin consulta. Máx. 5–7 líneas por pregunta.

Define interrupción con un ejemplo.
Define excepción con un ejemplo.
¿Qué es una system call y por qué existe?
¿Por qué existen user mode y kernel mode?

Próxima sesión

Sesión 4: El juego de la CPU (scheduling + context switch)

Lo visto hoy (timer + kernel + eventos) es la base para entender por qué el SO puede “turnar” procesos.