I read the below in operating systems and concepts by Galvin book

"A bit, called the mode bit, is added to the hardware of the computer to indicate the current mode: kernel(0) or user(1). With the mode bit, we are able to distinguish between a task that is executed on behalf of the operating system and one that is executed on behalf of the use"

Now if it's a multi processor system, then suppose a process executes a system call and changes the mode bit from 1 to 0 .

Now there might be some other processes running in user mode parallely as it's a multi processor system but the mode bit is set as 0 indicating kernel mode causing inconsistency.

So is the number of registers (required to store mode bit) dependent on number of processors ?

  • Thought experiment: Are there any registers which are not instanced per-processor (core)?
    – Ben Voigt
    Commented Oct 18, 2023 at 20:25

1 Answer 1


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.

  • 1
    Thanks for your answer. So to summarize, can I say that the hardware (register) required to store the bit is present individually for each processor if I go with the explanation present in the book?
    – Zephyr
    Commented Nov 25, 2017 at 4:17
  • 1
    Essentially yes at the risk of over simplifying it. Each processor/core has a state register which sets what level of permissions it has to IO including its ring. But for example the OS must also observe access rights in memory paging (protected memory) or switching from x86 real mode to protected mode which is what enables rings in the first place. So its incorrect to say there is one bit associated with what "kernel" mode is.
    – jdwolf
    Commented Nov 25, 2017 at 4:54
  • Galvin's book tries to be general, not specific to just one processor architecture. So I wouldn't say the book is oversimplifying things, it generalizes by not going into unnecessary detail. Each processor has its own conceptual supervisor mode bit, which means a process running on a particular CPU may be running in kernel mode independently of what the other CPUs are doing. Commented Nov 25, 2017 at 11:14
  • 1
    @Johan Myréen Then the proper way to explain it is that kernel mode is an abstraction for architecture specific security features as well as a model a particular OS uses rather then claiming an OS has a single bit that you just flip and suddenly kernel mode happens.
    – jdwolf
    Commented Nov 25, 2017 at 12:14
  • I actually rather like the kernel space / user space parlance as it accurately suggests that there are memory spaces protected by both kernel software and bare metal hardware features. As I explained though the hardware implementation of rings could easily do things that break the kernel mode / user mode mantra therefor "kernel mode" is just as much a software feature as it is a hardware one.
    – jdwolf
    Commented Nov 25, 2017 at 12:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .