Seu livro está simplificando demais as coisas. Na realidade, depende da CPU como o modo está definido e não é necessariamente um "bit" nem há necessariamente apenas dois modos.
Para o propósito da pergunta vamos supor que o Linux, Intel x86 e multicore.
A multitarefa é implementada com alternância de contexto, que no Linux é baseada em software. Um comutador de contexto apenas pára o que o processador está fazendo (um núcleo ou cpu), salva seu estado na RAM e o substitui por outro contexto.
Ox86 implementa anéis de proteção que podem ser definidos em cada processador antes que a execução no nível do processo ocorra. O kernel do Linux lida com isso definindo processos para tocar 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 rodando em um thread específico (geralmente 2 threads por core com intel), porque sempre que o código dos programas está rodando o kernel sempre configura o anel de volta para 3 mesmo O processador está vendo as alternâncias de contexto acontecerem muitas vezes por segundo, de modo que muitos processos estarão sendo executados no mesmo núcleo. Isso pode ser feito basicamente da mesma maneira com um ou vários núcleos.
No Linux com x86, quando um segmento deseja alternar 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ções de software, ele pode garantir que, mesmo que o encadeamento esteja agora no anel 0, ele só executa código em "espaço do kernel", significando código que faz parte do kernel, mesmo sendo o mesmo encadeamento que executava o código de espaço do usuário. No jargão do sistema operacional, isso é chamado de chamada de sistema, já que é o que realmente está fazendo. Se você quer considerar isso como o "processo" está mudando para o modo kernel e vice-versa ou que o processo está efetivamente em espera porque somente o código de espaço do kernel está sendo executado até que ele retorne para o userspace depende de você.
Como o x86 permite que aqueles em anéis altos mudem para os mais baixos, ele pode alternar de volta para 3 depois que o manipulador de interrupção for concluído. Isto é o que acontece com todas as chamadas do sistema para que todas as chamadas do sistema, do ponto de vista do hardware, possam fazer qualquer coisa no sistema. Ele poderia executar todas as instruções do seu programa ao contrário e excluir todo o seu código da memória, se quisesse. Ou pode ser 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 / user", já que esse conceito não existe no hardware. No linux, porém, ele sempre é implementado como uma chamada ao espaço do kernel e um retorno ao espaço do usuário (efetivamente, a memória não é protegida do anel 0 no x86).
Portanto, a comutação de modo de kernel / usuário é implementada usando um manipulador de interrupções de software que pode romper o anel de proteção de threads, mas é implementado de tal forma que a execução só ocorre no espaço do kernel e é retornada ao userspace, especificamente o processo userspace que executou o syscall mas só depois de retornar ao anel 3.