Your book is oversimplifying things. In reality it depends on the CPU how the mode is set and its not necessarily a "bit" at all nor are there necessarily only two modes.
For the purpose of the question lets assume Linux, Intel x86 and multicore.
Multitasking is implemented with context switching which in Linux is software based. A context switch just stops what the processor is doing (a core or cpu), saves its state to RAM and then replaces it with another context.
x86 implements protection rings that can be set on each processor before process level execution occurs. The Linux kernel handles this by setting processes to ring 3 (unprivileged) before starting execution in their memory space. Through the implementation of context switching mentioned earlier the kernel maintains the concept of a process running on a specific thread (often 2 threads per core with intel) because when ever that programs code is running the kernel always sets the ring back to 3 even though the processor is seeing context switches happening many times a second so that many processes will be running on the same core. It can do this essentially the same way with one or many cores.
On Linux with x86 when a thread wants to switch from ring 3 to ring 0 (supervisor) it can only do this with a software interrupt. In rings 1 and 2 its also possible with special instructions but Linux doesn't implement this. Because Linux controls the software interrupt handler it can ensure even though the thread is now in ring 0 it only runs code in "kernel space" meaning in code that is part of the kernel even though its the same thread that was executing user space code. In operating system parlance this is just called a system call as thats what its really doing. Whether you want to consider this as the "process" is switching to kernel mode and back or that the process is effectively on hold because only kernel space code is being executed until it hands back off to userspace is up to you.
Because x86 allows those in high rings to switch to lower ones it can then switch back to 3 after the interrupt handler is completed. This is what happens with all system calls therefor all system calls from the hardware perspective can do anything on the system. It could run every instruction of your program in reverse and then delete all your code from memory if it wanted. Or it could be switch to ring 0 and begin execution at the start of your program. As you can see these examples break the idea of "kernel/user" mode as no such concept exists in hardware. On linux however its always implemented as a call into kernel space and a return to user space (effectively memory not protected form ring 0 on x86).
Therefor kernel/user mode switching is implemented by using a software interrupt handler which can break out of the threads protection ring but is implemented such that execution only then occurs in kernel space and is then returned back to userspace, specifically the userspace process that executed the syscall but only after returning to ring 3.
