Eu li o abaixo em sistemas operacionais e conceitos do livro Galvin
"Um bit, chamado bit de modo, é adicionado ao hardware do computador para indicar o modo atual: kernel(0) ou usuário(1). Com o bit de modo, somos capazes de distinguir entre uma tarefa executada em nome do sistema operacional e aquele que é executado em nome do uso"
Agora, se for um sistema multiprocessador, suponha que um processo execute uma chamada de sistema e altere o bit de modo de 1 para 0 .
Agora, pode haver alguns outros processos em execução no modo de usuário paralelamente, pois é um sistema multiprocessador, mas o bit de modo é definido como 0, indicando o modo kernel causando inconsistência.
Então, o número de registradores (necessários para armazenar o bit de modo) depende do número de processadores?
Seu livro está simplificando demais as coisas. Na realidade, depende da CPU como o modo é definido e não é necessariamente um "bit" nem existem necessariamente apenas dois modos.
Para o propósito da questão, vamos supor Linux, Intel x86 e multicore.
A multitarefa é implementada com alternância de contexto, que no Linux é baseada em software. Uma troca de contexto apenas interrompe o que o processador está fazendo (um núcleo ou CPU), salva seu estado na RAM e o substitui por outro contexto.
O x86 implementa anéis de proteção que podem ser definidos em cada processador antes que ocorra a execução no nível do processo. O kernel do Linux lida com isso configurando os processos para tocar 3 (sem privilégios) antes de iniciar a execução em seu espaço de memória. Por meio da implementação da troca de contexto mencionada anteriormente, o kernel mantém o conceito de um processo em execução em um thread específico (geralmente 2 threads por núcleo com intel) porque sempre que o código do programa está sendo executado, o kernel sempre define o anel de volta para 3, mesmo que o processador está vendo mudanças de contexto acontecendo muitas vezes por segundo para que muitos processos sejam executados no mesmo núcleo. Ele pode fazer isso essencialmente da mesma maneira com um ou mais núcleos.
No Linux com x86, quando um thread deseja mudar do anel 3 para o anel 0 (supervisor), ele só pode fazer isso com uma interrupção de software. Nos anéis 1 e 2 também é possível com instruções especiais, mas o Linux não implementa isso. Como o Linux controla o manipulador de interrupção do software, ele pode garantir que, mesmo que o encadeamento esteja agora no anel 0, ele execute apenas o código no "espaço do kernel", o que significa código que faz parte do kernel, embora seja o mesmo encadeamento que estava executando o código do espaço do usuário. Na linguagem do sistema operacional, isso é chamado apenas de chamada do sistema, pois é o que realmente está fazendo. Se você deseja considerar isso como o "processo" está alternando para o modo kernel e vice-versa ou que o processo está efetivamente em espera porque apenas o código de espaço do kernel está sendo executado até que seja devolvido ao espaço do usuário, depende de você.
Como o x86 permite que aqueles em anéis altos mudem para os mais baixos, ele pode voltar para 3 depois que o manipulador de interrupção for concluído. Isso é o que acontece com todas as chamadas de sistema, pois todas as chamadas de sistema da perspectiva do hardware podem fazer qualquer coisa no sistema. Ele poderia executar todas as instruções do seu programa ao contrário e, em seguida, excluir todo o seu código da memória, se quisesse. Ou pode ser alternar para o anel 0 e iniciar a execução no início do seu programa. Como você pode ver, esses exemplos quebram a ideia do modo "kernel/usuário", pois esse conceito não existe no hardware. No linux, no entanto, é sempre implementado como uma chamada para o espaço do kernel e um retorno ao espaço do usuário (memória efetivamente não protegida do anel 0 em x86).
Portanto, a alternância de modo kernel/usuário é implementada usando um manipulador de interrupção de software que pode sair do anel de proteção de threads, mas é implementado de forma que a execução ocorra apenas no espaço do kernel e seja retornada ao espaço do usuário, especificamente o processo do espaço do usuário que executou o syscall, mas somente após retornar ao anel 3.