Cambio de contexto

En informática, un cambio de contexto es el proceso de almacenar el estado de un proceso o subproceso, de modo que pueda restaurarse y reanudar la ejecución en un punto posterior, y luego restaurar un estado diferente previamente guardado, estado. Esto permite que múltiples procesos compartan una sola unidad central de procesamiento (CPU) y es una característica esencial de un sistema operativo multitarea.

El significado preciso de la frase "cambio de contexto" varía En un contexto multitarea, se refiere al proceso de almacenar el estado del sistema para una tarea, de modo que esa tarea se pueda pausar y reanudar otra tarea. 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 moverse entre el modo de usuario y las tareas del modo kernel. El proceso de cambio de contexto puede tener un impacto negativo en el rendimiento del sistema.

Coste

Los cambios de contexto suelen ser computacionalmente intensivos, y gran parte del diseño de los sistemas operativos es para optimizar el uso de 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 pila y el contador del programa, así como la información de administración de la memoria, como las tablas de segmentación y las 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 la traducción incorrecta de direcciones en el caso de que los procesos anteriores y actuales utilicen una 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 a la TLB se perderá porque está vacía después de la mayoría de los cambios de contexto.

Además, el cambio de contexto análogo ocurre entre los subprocesos de los usuarios, en particular los subprocesos verdes, y suele ser muy ligero, guardando y restaurando un contexto mínimo. En casos extremos, como cambiar entre rutinas en Go, un cambio de contexto es equivalente a un rendimiento de rutina, que es solo marginalmente más costoso que una llamada de subrutina.

Cambio de casos

Hay tres desencadenantes potenciales para un cambio de contexto:

Multitarea

Por lo general, dentro de algún esquema de programación, un proceso debe desconectarse de la CPU para que pueda ejecutarse otro proceso. Este cambio de contexto puede activarse cuando el proceso no se puede ejecutar, por ejemplo, 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 cambiar los procesos que aún se pueden ejecutar. Para evitar que otros procesos se queden sin 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 asegura que el programador obtenga el control para realizar un cambio de contexto.

Manejo de interrupciones

Las arquitecturas modernas se basan en interrupciones. Esto significa que si la CPU solicita datos de un disco, por ejemplo, no necesita estar ocupado esperando hasta que termine 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 (por un hardware en este caso, que envía una solicitud de interrupción a 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 desde el 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 en particular. A menudo, solo se cambia una parte mínima del contexto para minimizar la cantidad de tiempo dedicado al manejo de la interrupción. El núcleo 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, se restaura el contexto vigente antes de que ocurriera la interrupción para que el proceso interrumpido pueda reanudar la ejecución en su estado adecuado.

Cambio de modo de usuario y kernel

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 ocurrir un cambio de contexto en este momento.

Pasos

El estado del proceso que se está ejecutando actualmente se debe guardar para que se pueda restaurar cuando se reprograme para su ejecución.

El estado del proceso incluye todos los registros que el proceso puede 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 proceso (PCB) o switchframe.

El PCB puede almacenarse en una pila por proceso en la memoria del kernel (a diferencia de la pila de llamadas en modo 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 llamada cola lista.

Dado que el sistema operativo suspendió 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 de programa de la PCB y, por lo tanto, la ejecución puede continuar en el proceso elegido. La prioridad del proceso y del subproceso puede influir en qué proceso se elige de la cola lista (es decir, puede ser una cola prioritaria).

Ejemplo

Considerando una operación de suma aritmética general A = B+1. La instrucción se almacena en el registro de instrucciones y el contador de programa se incrementa. A y B se leen de la memoria y se almacenan en los registros R1, R2 respectivamente. En este caso, se calcula B+1 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 de función utilizadas, por lo tanto, no se produce cambio de contexto/espera en este caso.

Sin embargo, ciertas instrucciones especiales requieren llamadas al sistema que requieren un cambio de contexto para procesos de espera/suspensión. 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 de visualización () entra en suspensión y espera la operación de LECTURA para obtener el valor de x del disco, lo que hace que el programa para esperar y esperar una llamada de función a la versión liberada configurando la declaración actual para ir a dormir y esperar a que la llamada al sistema la despierte. Sin embargo, para mantener la simultaneidad, el programa necesita volver a ejecutar el nuevo valor y el proceso de dormir juntos nuevamente.

Rendimiento

El cambio de contexto en sí mismo 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 la memoria caché de la CPU entre varias tareas. Cambiar 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.

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 se denomina latencia de interrupción.

Cambiar entre dos procesos en un solo sistema operativo de 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.

Hardware frente a software

El cambio de contexto se puede realizar principalmente mediante software o hardware. Algunos procesadores, como el Intel 80386 y sus sucesores, tienen soporte de hardware para cambios de contexto, al hacer 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 tareas en la tabla de descriptores de interrupción (IDT). Cuando ocurre 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 esto fuera bastante rápido; sin embargo, los principales sistemas operativos, incluidos Windows y Linux, no utilizan esta función. Esto se debe principalmente a dos razones:

• El cambio de contexto de hardware no guarda todos los registros (sólo los registros generales, no los registros de puntos flotantes), aunque los registros de puntos TS bit se activa automáticamente en el CR0 registro de control, resultando en una falla al ejecutar instrucciones de punto flotante y dar al sistema operativo la oportunidad de salvar y restaurar el estado de punto flotante según sea necesario).
• Los problemas de rendimiento asociados, por ejemplo, la conmutación del contexto de software puede ser selectiva y almacenar sólo los registros que necesitan almacenamiento, mientras que la conmutación del contexto de hardware almacena casi todos los registros si son necesarios o no.