Eu li o abaixo no livro Sistemas Operacionais e Conceitos do 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, podemos distinguir entre uma tarefa que é 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 registros (necessários para armazenar o bit de modo) depende do número de processadores?
Responder1
Seu livro está simplificando demais as coisas. Na realidade, depende da CPU como o modo é definido e não é necessariamente um "bit" nem há necessariamente apenas dois modos.
Para efeito da questão, vamos supor Linux, Intel x86 e multicore.
A multitarefa é implementada com troca 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 o anel 3 (sem privilégios) antes de iniciar a execução em seu espaço de memória. Através 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á em execução, o kernel sempre define o anel de volta para 3, mesmo que o O processador está vendo mudanças de contexto acontecendo muitas vezes por segundo, de modo que muitos processos estarão sendo executados no mesmo núcleo. Isso pode ser feito 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 de software, ele pode garantir que, mesmo que o thread esteja agora no anel 0, ele execute apenas o código no "espaço do kernel", ou seja, no código que faz parte do kernel, mesmo que seja o mesmo thread que estava executando o código do espaço do usuário. Na linguagem do sistema operacional, isso é chamado apenas de chamada de sistema, pois é isso que realmente está fazendo. Se você deseja considerar isso como o "processo" está mudando para o modo kernel e vice-versa ou que o processo está efetivamente em espera porque apenas o código do espaço do kernel está sendo executado até que ele retorne ao espaço do usuário, depende de você.
Como o x86 permite que aqueles em anéis altos mudem para anéis mais baixos, ele pode voltar para 3 após a conclusão do manipulador de interrupção. Isto é o que acontece com todas as chamadas do sistema; portanto, todas as chamadas do 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 mudar para o anel 0 e começar a execução no início do seu programa. Como você pode ver, esses exemplos quebram a ideia do modo "kernel/usuário", já que tal conceito não existe em hardware. No Linux, entretanto, é sempre implementado como uma chamada ao espaço do kernel e um retorno ao espaço do usuário (efetivamente memória não protegida do anel 0 no x86).
Portanto, a troca 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 só ocorre no espaço do kernel e é então retornada de volta ao espaço do usuário, especificamente o processo do espaço do usuário que executou o syscall, mas somente depois de retornar ao toque 3.