Leí lo siguiente en sistemas operativos y conceptos del libro de Galvin.
"Un bit, llamado bit de modo, se agrega al hardware de la computadora para indicar el modo actual: kernel(0) o usuario(1). Con el bit de modo, podemos distinguir entre una tarea que se ejecuta en en nombre del sistema operativo y uno que se ejecuta en nombre del uso"
Ahora bien, si se trata de un sistema multiprocesador, supongamos que un proceso ejecuta una llamada al sistema y cambia el bit de modo de 1 a 0.
Ahora bien, es posible que haya otros procesos ejecutándose en modo de usuario en paralelo, ya que es un sistema multiprocesador, pero el bit de modo está establecido en 0, lo que indica que el modo kernel causa inconsistencia.
Entonces, ¿la cantidad de registros (requeridos para almacenar bits en modo) depende de la cantidad de procesadores?
Respuesta1
Su libro está simplificando demasiado las cosas. En realidad, depende de la CPU cómo se configura el modo y no es necesariamente un "bit" en absoluto ni necesariamente hay sólo dos modos.
A los efectos de la pregunta, supongamos Linux, Intel x86 y multinúcleo.
La multitarea se implementa con cambio de contexto, que en Linux se basa en software. Un cambio de contexto simplemente detiene lo que está haciendo el procesador (un núcleo o CPU), guarda su estado en la RAM y luego lo reemplaza con otro contexto.
x86 implementa anillos de protección que se pueden configurar en cada procesador antes de que ocurra la ejecución a nivel de proceso. El kernel de Linux maneja esto configurando los procesos en el timbre 3 (sin privilegios) antes de comenzar la ejecución en su espacio de memoria. A través de la implementación del cambio de contexto mencionado anteriormente, el kernel mantiene el concepto de un proceso que se ejecuta en un subproceso específico (a menudo, 2 subprocesos por núcleo con Intel) porque cada vez que se ejecuta el código de ese programa, el kernel siempre establece el anillo nuevamente en 3, aunque el El procesador ve cambios de contexto que ocurren muchas veces por segundo, por lo que muchos procesos se ejecutarán en el mismo núcleo. Puede hacer esto esencialmente de la misma manera con uno o varios núcleos.
En Linux con x86, cuando un hilo quiere cambiar del anillo 3 al anillo 0 (supervisor), solo puede hacerlo con una interrupción de software. En los anillos 1 y 2 también es posible con instrucciones especiales, pero Linux no implementa esto. Debido a que Linux controla el controlador de interrupciones del software, puede garantizar que, aunque el subproceso esté ahora en el anillo 0, solo ejecute código en el "espacio del kernel", es decir, en el código que es parte del kernel, aunque sea el mismo subproceso que estaba ejecutando el código del espacio del usuario. En el lenguaje del sistema operativo, esto se llama simplemente llamada al sistema, ya que eso es lo que realmente hace. Depende de usted si desea considerar esto como que el "proceso" está cambiando al modo kernel y viceversa o que el proceso está efectivamente en espera porque solo se ejecuta el código del espacio del kernel hasta que vuelve al espacio de usuario.
Debido a que x86 permite que aquellos en anillos altos cambien a anillos inferiores, luego puede volver a 3 después de que se complete el controlador de interrupciones. Esto es lo que sucede con todas las llamadas al sistema, por lo que todas las llamadas al sistema desde la perspectiva del hardware pueden hacer cualquier cosa en el sistema. Podría ejecutar cada instrucción de su programa a la inversa y luego eliminar todo su código de la memoria si así lo desea. O podría cambiar al timbre 0 y comenzar la ejecución al inicio de su programa. Como puede ver, estos ejemplos rompen la idea del modo "núcleo/usuario", ya que tal concepto no existe en el hardware. Sin embargo, en Linux siempre se implementa como una llamada al espacio del kernel y un retorno al espacio del usuario (efectivamente, la memoria no está protegida desde el anillo 0 en x86).
Por lo tanto, el cambio de modo kernel/usuario se implementa mediante el uso de un controlador de interrupciones de software que puede salir del anillo de protección de subprocesos, pero se implementa de manera que la ejecución solo ocurre en el espacio del kernel y luego regresa al espacio de usuario, específicamente al proceso del espacio de usuario que ejecutó el syscall pero solo después de regresar al timbre 3.