This is my understanding:

There are two types of processes: user and kernel(OS). Each process can have single or multiple threads. The threads of a user process are called a user-level thread and the threads of a kernel process are called kernel-level threads. Scheduler, dispatcher etc. contains kernel-level threads. Both user-level threads and kernel-level threads can able to run on CPU.

There may be several user-processes in ready queue for execution, scheduler(kernel) decides which user process/ thread to run on CPU, dispatcher(kernel) gives control to the corresponding user-thread on CPU, the corresponding user-thread executes and terminates.

Consider the following statement (From Galvin os textbook):

To run on a CPU, user-level threads must ultimately mapped to an associated kernel-level thread.

My doubt is as follows:

What is the need of such mapping? Where am I going wrong?

  • $\begingroup$ Hint: Find about what happens when a system call is made in a user level thread. It cannot simply continue as it has no privilege to execute system call routines. $\endgroup$ Apr 23, 2017 at 7:04
  • $\begingroup$ @Devendra Then control on cpu goes to corresponding kernel threads $\endgroup$
    – hanugm
    Apr 23, 2017 at 8:50

1 Answer 1


I don't know the book, so what follows is only my speculation. Take it as such.

"User vs kernel level threads" might mean two different things. Carefully check your book terminology.

One interpretation is that user level threads are those who execute users' programs, while kernel level threads execute OS code. This is the interpretation you described in your question.

Another possible interpretation is the following. The OS provides processes and threads as usual. Within a OS-provided thread CPU time, user code might choose to run several subroutines concurrently. I.e., within the same OS thread, user code can execute a subroutine for 100ms, and then jump to another one for 100ms, and so on. Essentially, the user code is implementing a scheduler among several sub-threads. These "simulated" threads can be named "user level threads". In practice, some programming language implementations provide these, often called "green threads" or something similar. Note that the OS is completely unaware of those user level threads.

If at that point your book is referring to such threads, then the sentence you quoted simply means that each user thread, to be executed, must be run inside a OS provided thread. A simple implementation is to map N user level threads to a single OS thread, but running N user threads exploiting M OS threads is also possible.

  • 1
    $\begingroup$ In my experience the standard meaning for user-level threads vs kernel-level threads is your second interpretation, not the first -- and I think that makes sense in context as well. (Both of them run user code; the difference is (basically) between whether it's done with or without OS support, i.e., whether scheduling decisions are made by a user-space library or by the kernel.) $\endgroup$
    – D.W.
    Apr 23, 2017 at 17:31
  • 1
    $\begingroup$ @D.W. In my experience it's the second one as well. Yet, the OP mentioned the first one, so I wondered if the book used the first one, or the OP simply misunderstood. (Probably the latter, since the OP was confused by the book statement, which fits perfectly with the second interpretation.) $\endgroup$
    – chi
    Apr 23, 2017 at 20:00
  • $\begingroup$ Yeah @chi, I got confuse. Let stick to 2nd definition. Suppose $S_1,S_2$ are OS threads. $U_1,U_2$ are user threads(Simulated/ OS is unaware). If the execution on CPU happened like this $S_1,U_1,S_1,U_2,S_1$. Then is it called Many-to-one mapping? If happens like $S_1,U_1,S_1,S_2,U_2,S_2$, is it called many-to-many mapping? Is the mapping depends up on the order of execution on CPU? $\endgroup$
    – hanugm
    Apr 24, 2017 at 0:26
  • 1
    $\begingroup$ @hanugm IT makes no sense to have $S_1,U_1$ -- $U_1$ can not run at all on the CPU unless it is within some OS thread. It is something like $S_1,S_2(U_1), S_2(U_2), S_1, \ldots$. There, I mapped two user threads to the same OS thread. $\endgroup$
    – chi
    Apr 24, 2017 at 7:34
  • $\begingroup$ Thanks for the answer! In Gilles' reply, did he mean the first or second interpretation of yours by "kernel-level" and "user-level" threads? $\endgroup$
    – Tim
    Oct 25, 2017 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.