En informática , un cambio de contexto es el proceso de almacenar el estado de un proceso o subproceso , para que pueda restaurarse y reanudar la ejecución en un momento posterior, y luego restaurar un estado diferente, previamente guardado. [1] Esto permite que múltiples procesos compartan una única unidad central de procesamiento (CPU) y es una característica esencial de un sistema operativo multiprogramación o multitarea . En una CPU tradicional, cada proceso (un programa en ejecución) utiliza los distintos registros de la CPU para almacenar datos y mantener el estado actual del proceso en ejecución. Sin embargo, en un sistema operativo multitarea, el sistema operativo cambia entre procesos o subprocesos para permitir la ejecución de múltiples procesos simultáneamente. Para cada cambio, el sistema operativo debe guardar el estado del proceso que se está ejecutando actualmente, seguido de cargar el siguiente estado del proceso, que se ejecutará en la CPU. Esta secuencia de operaciones que almacena el estado del proceso en ejecución y la carga del siguiente proceso en ejecución se denomina cambio de contexto.
El significado preciso de la frase "cambio de contexto" varía. En un contexto de multitarea, se refiere al proceso de almacenar el estado del sistema para una tarea, de modo que esa tarea pueda pausarse y reanudarse otra. Un cambio de contexto también puede ocurrir como resultado de una interrupción , como cuando una tarea necesita acceder al almacenamiento en disco , liberando tiempo de CPU para otras tareas. Algunos sistemas operativos también requieren un cambio de contexto para pasar del modo de usuario al modo de kernel . El proceso de cambio de contexto puede tener un impacto negativo en el rendimiento del sistema. [2] : 28
Los cambios de contexto suelen ser intensivos en términos computacionales y gran parte del diseño de los sistemas operativos tiene como objetivo optimizar el uso de los cambios de contexto. Cambiar de un proceso a otro requiere una cierta cantidad de tiempo para realizar la administración: guardar y cargar registros y mapas de memoria, actualizar varias tablas y listas, etc. Lo que realmente implica un cambio de contexto depende de las arquitecturas, los sistemas operativos y la cantidad de recursos compartidos (los subprocesos que pertenecen al mismo proceso comparten muchos recursos en comparación con procesos no relacionados que no cooperan).
Por ejemplo, en el kernel de Linux , el cambio de contexto implica cargar el bloque de control de proceso (PCB) correspondiente almacenado en la tabla de PCB en la pila del kernel para recuperar información sobre el estado del nuevo proceso. La información del estado de la CPU, incluidos los registros, el puntero de la pila y el contador del programa , así como información de administración de la memoria, como tablas de segmentación y tablas de páginas (a menos que el proceso anterior comparta la memoria con el nuevo), se cargan desde la PCB para el nuevo proceso. Para evitar una traducción incorrecta de direcciones en el caso de que los procesos anterior y actual utilicen memoria diferente, se debe vaciar el búfer de búsqueda de traducción (TLB). Esto afecta negativamente al rendimiento porque cada referencia de memoria al TLB se perderá porque estará vacía después de la mayoría de los cambios de contexto. [3] [4]
Además, el cambio de contexto análogo ocurre entre hilos de usuario , en particular hilos verdes , y suele ser muy ligero, ahorrando y restaurando un contexto mínimo. En casos extremos, como el cambio entre gorutinas en Go , un cambio de contexto es equivalente a un rendimiento de corrutina , que es sólo marginalmente más caro que una llamada a subrutina .
Hay tres posibles desencadenantes de un cambio de contexto:
Lo más habitual es que, dentro de algún esquema de programación , se deba desconectar un proceso de la CPU para que pueda ejecutarse otro proceso. Este cambio de contexto puede desencadenarse cuando el proceso se vuelve inejecutable, como al esperar a que se complete una operación de E/S o de sincronización . En un sistema multitarea preventivo , el programador también puede desactivar procesos que aún son ejecutables. Para evitar que otros procesos se vean privados de tiempo de CPU, los programadores preventivos a menudo configuran una interrupción del temporizador para que se active cuando un proceso excede su intervalo de tiempo . Esta interrupción garantiza que el programador obtendrá el control para realizar un cambio de contexto.
Las arquitecturas modernas están impulsadas por las interrupciones . Esto significa que si la CPU solicita datos de un disco, por ejemplo, no necesita estar ocupada y esperar hasta que finalice la lectura; puede emitir la solicitud (al dispositivo de E/S) y continuar con alguna otra tarea. Cuando finaliza la lectura, la CPU puede ser interrumpida (mediante un hardware en este caso, que envía una solicitud de interrupción al PIC ) y presentar la lectura. Para las interrupciones, se instala un programa llamado controlador de interrupciones , y es el controlador de interrupciones el que maneja la interrupción del disco.
Cuando ocurre una interrupción, el hardware cambia automáticamente una parte del contexto (al menos lo suficiente para permitir que el controlador regrese al código interrumpido). El controlador puede guardar contexto adicional, dependiendo de los detalles de los diseños de hardware y software particulares. A menudo, sólo se cambia una parte mínima del contexto para minimizar la cantidad de tiempo dedicado a manejar la interrupción. El kernel no genera ni programa un proceso especial para manejar las interrupciones, sino que el controlador se ejecuta en el contexto (a menudo parcial) establecido al comienzo del manejo de interrupciones. Una vez que se completa el servicio de interrupción, el contexto vigente antes de que ocurriera la interrupción se restaura para que el proceso interrumpido pueda reanudar la ejecución en su estado adecuado.
Cuando el sistema cambia entre el modo de usuario y el modo kernel , no es necesario un cambio de contexto; una transición de modo no es en sí misma un cambio de contexto. Sin embargo, dependiendo del sistema operativo, también puede producirse un cambio de contexto en este momento.
El estado del proceso que se está ejecutando actualmente debe guardarse para que pueda restaurarse cuando se reprograme su ejecución.
El estado del proceso incluye todos los registros que el proceso pueda estar utilizando, especialmente el contador del programa , además de cualquier otro dato específico del sistema operativo que pueda ser necesario. Esto generalmente se almacena en una estructura de datos llamada bloque de control de procesos (PCB) o switchframe .
La PCB puede almacenarse en una pila por proceso en la memoria del kernel (a diferencia de la pila de llamadas en modo de usuario ), o puede haber alguna estructura de datos específica definida por el sistema operativo para esta información. Se agrega un identificador a la PCB a una cola de procesos que están listos para ejecutarse, a menudo denominada cola lista .
Dado que el sistema operativo ha suspendido efectivamente la ejecución de un proceso, puede cambiar de contexto eligiendo un proceso de la cola lista y restaurando su PCB. Al hacerlo, se carga el contador del programa de la PCB y, por lo tanto, la ejecución puede continuar en el proceso elegido. La prioridad de los procesos y subprocesos puede influir en qué proceso se elige de la cola lista (es decir, puede ser una cola prioritaria ).
Considerando una operación de suma aritmética general A = B+1. La instrucción se almacena en el registro de instrucciones y se incrementa el contador del programa . A y B se leen de la memoria y se almacenan en los registros R1, R2 respectivamente. En este caso, B+1 se calcula y se escribe en R1 como respuesta final. Esta operación, ya que hay lecturas y escrituras secuenciales y no hay esperas para las llamadas a funciones utilizadas, por lo tanto, en este caso no se produce ningún cambio/espera de contexto.
Sin embargo, ciertas instrucciones especiales requieren llamadas al sistema que requieren un cambio de contexto para esperar/dormir procesos. Se utiliza un controlador de llamadas del sistema para el cambio de contexto al modo kernel . Una función de visualización (datos x) puede requerir datos x del disco y un controlador de dispositivo en modo kernel, por lo tanto, la función display() entra en suspensión y espera la operación READ para obtener el valor de x del disco , lo que hace que el programa esperar y esperar a que se llame a la función para configurar la configuración liberada para que la declaración actual entre en suspensión y espere a que la llamada al sistema la active. Sin embargo, para mantener la concurrencia , el programa debe volver a ejecutar el nuevo valor y el proceso de suspensión juntos nuevamente.
El cambio de contexto en sí tiene un costo en el rendimiento, debido a la ejecución del programador de tareas , los vaciados de TLB e indirectamente debido a que se comparte el caché de la CPU entre múltiples tareas. [5] El cambio entre subprocesos de un solo proceso puede ser más rápido que entre dos procesos separados, porque los subprocesos comparten los mismos mapas de memoria virtual , por lo que no es necesario un vaciado de TLB. [6]
El tiempo para cambiar entre dos procesos separados se denomina latencia de cambio de proceso . El tiempo para cambiar entre dos subprocesos del mismo proceso se denomina latencia de cambio de subproceso . El tiempo desde que se genera una interrupción de hardware hasta que se atiende la interrupción se denomina latencia de interrupción .
Cambiar entre dos procesos en un sistema operativo con un único espacio de direcciones puede ser más rápido que cambiar entre dos procesos en un sistema operativo con espacios de direcciones privados por proceso. [7]
El cambio de contexto se puede realizar principalmente mediante software o hardware. Algunos procesadores, como el Intel 80386 y sus sucesores, [8] tienen soporte de hardware para cambios de contexto, mediante el uso de un segmento de datos especial denominado segmento de estado de tarea (TSS). Un cambio de tarea se puede activar explícitamente con una instrucción CALL o JMP dirigida a un descriptor TSS en la tabla de descriptores globales . Puede ocurrir implícitamente cuando se activa una interrupción o excepción si hay una puerta de tarea en la tabla de descriptores de interrupción (IDT). Cuando se produce un cambio de tarea, la CPU puede cargar automáticamente el nuevo estado desde el TSS.
Al igual que con otras tareas realizadas en hardware, uno esperaría que fuera bastante rápido; sin embargo, los principales sistemas operativos, incluidos Windows y Linux , [9] no utilizan esta función. Esto se debe principalmente a dos motivos:
TS , aunque el bit se activa automáticamente en el CR0 registro de control , lo que genera una falla al ejecutar instrucciones de punto flotante y le da al sistema operativo la oportunidad de guardar y restaurar el estado de punto flotante según sea necesario).El cambio de contexto es el núcleo del acto de malabarismo entre procesos. Consiste en detener el cálculo actual, guardar suficiente información para poder reiniciarlo más tarde y reiniciar otro proceso.