En informática, el contexto de una tarea (proceso, hilo, rutina de servicio...) es el conjunto de información mínima que describe el estado de esa tarea en un instante dado y que debe guardarse para permitir su interrupción y posterior reanudación exactamente en el mismo punto. El concepto adquiere especial importancia en sistemas con multitarea o con interrupciones: cuando una tarea es interrumpida, el procesador y el sistema operativo guardan su contexto para poder atender la interrupción y, más adelante, restaurarlo y continuar la ejecución. Cuanto menor sea el contexto que haya que salvar y restaurar, menor será la latencia del cambio y mayor la eficacia del sistema.

Elementos que suelen formar el contexto

  • Registros del procesador —por ejemplo contador de programa (PC/EIP/RIP), puntero de pila (SP/ESP/RSP), registros de propósito general y registros de estado/flags—
  • Memoria utilizada por la tarea —principalmente la pila del hilo y, en algunos casos, estructuras asociadas al heap o áreas reservadas—
  • En algunos sistemas operativos, los registros de control utilizados por el sistema para gestionar la tarea —por ejemplo registros de contexto de memoria (p. ej. CR3/NPT/TTBR), descriptores de segmento o índices de tabla de páginas—
  • Otros elementos de estado del proceso o hilo: máscara de señales, tabla de descriptores de archivos abiertos (descritores), atributos de prioridad, información de planificador y estado del FPU/SIMD (fpu, SSE, AVX) que puede necesitar guardado/restaurado

Es importante distinguir entre distintos tipos de estado:

  • Contexto de CPU: registros y banderas que necesita el procesador para continuar la ejecución.
  • Estado del kernel: estructuras en memoria del sistema operativo (por ejemplo el PCB o task_struct) que describen la tarea.
  • Estado persistente: archivos en disco y datos guardados que no se ven afectados por un cambio de contexto ordinario. Aunque los archivos en almacenamiento permanente no cambian por un context switch, algunos sistemas utilizan técnicas de checkpointing para persistir el estado completo de una tarea a disco y permitir recuperación ante fallos.

Cambio de contexto (context switch): qué ocurre y por qué cuesta

Un cambio de contexto es la operación por la cual el sistema guarda el contexto de la tarea actual y carga el contexto de otra. Pasos típicos:

  • El procesador y/o la rutina de interrupción guardan los registros críticos (a veces mediante hardware que empuja automáticamente algunos registros al stack).
  • El sistema operativo completa el guardado del contexto en la estructura de control del proceso/hilo (PCB, TCB).
  • El planificador elige la siguiente tarea a ejecutar y el sistema carga su contexto desde la estructura correspondiente.
  • Se actualizan estructuras de memoria (p. ej. tablas de páginas) y se restauran registros; tras ello la CPU reanuda la ejecución en el nuevo contexto.

La conmutación tiene un coste en tiempo (latencia) y en recursos: operaciones de lectura/escritura en memoria, invalidez de cachés y TLB, y el trabajo del planificador. Por eso hay distinciones prácticas:

  • Context switch entre hilos del mismo proceso suele ser más barato porque comparten tablas de páginas y recursos.
  • Context switch entre procesos es más caro si implica cambiar el espacio de direcciones (flush de TLB, recarga de registros de control).
  • Interrupciones y excepciones a menudo guardan solo el contexto mínimo necesario para atender el evento y luego delegan en el sistema operativo el guardado completo si es necesario.

Optimización y soporte hardware

Para reducir el coste se emplean técnicas como el guardado perezoso de registros (guardar estados del FPU/SIMD solo cuando se necesite), estructuras hardware de soporte (TSS en x86, hilos ligeros a nivel de CPU en algunos diseños), y optimizaciones del planificador para agrupar tareas afines (affinity). También existen mecanismos para realizar checkpointing y migración de procesos en entornos de alta disponibilidad o contenedores.

En resumen, el contexto engloba los datos necesarios para que una tarea pueda detenerse y reanudarse sin pérdida de información. Su tamaño y la forma en que se gestiona condicionan la latencia de las interrupciones y cambios de tarea, y son factores clave para el diseño de sistemas operativos y arquitecturas eficientes.