5
$\begingroup$

The following is an excerpt from OS concepts by galvin.Here is the book.

Multithreading Models

Our discussion so far has treated threads in a generic sense. However, support for threads may be provided either at the user level, for user threads, or by the kernel, for kernel threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system. Virtually all contemporary operating systems—including Windows, Linux, Mac OS X , and Solaris— support kernel threads.

Ultimately, a relationship must exist between user threads and kernel threads.

It then goes on to discuss Many-To-One Model,One-To-One Model and Many-To-Many Model.

Question :
Why there must be a relationship between user threads and kernel threads?

Does kernel thread here means a thread of the kernel(i.e OS)? I don't think so since it clearly specifies that it relates to support for threads.

Improve this question
$\endgroup$
5
  • $\begingroup$ I just thought of the following reasoning. A process must be connected to the OS. The OS is only aware of Kernel threads of the process. Now, for a user thread to contact the OS it must do it through a kernel thread of the process. $\endgroup$
    – PleaseHelp
    Commented Nov 10, 2015 at 11:32
  • $\begingroup$ I have an issue with the word Must in your statements. Though I suspect it's an issue with definitions and semantics. There are Kernel threads that have no direct relation to User threads (the interrupt handler for the clock to update system time is one example). But if the suggestion was that all User threads must have some relation to Kernel threads, then I'd agree, if nothing else for thread creation and scheduling, but also most system service calls can be thought of as a Kernel thread. I'd also argue that User threads ARE "managed" by the kernel, but again it may be semantics, $\endgroup$
    – Brian Hibbert
    Commented Nov 10, 2015 at 12:50
  • $\begingroup$ @BrianHibbert the book defines Kernel threads as threads visible/managed by the OS/kernel and not as the kernel itself. $\endgroup$
    – PleaseHelp
    Commented Nov 10, 2015 at 13:34
  • $\begingroup$ Like I said.... definitions and semantics. I'll have to look at their book to see how they define Kernel and User threads.... looks like chapter 4 covers threads. $\endgroup$
    – Brian Hibbert
    Commented Nov 10, 2015 at 13:57
  • $\begingroup$ OK, I see where their definitions are leading now. They are trying to explain the difference between who manages the scheduling of threads... but I think it's more than I can fit in a comment. I'll ad an answer below. $\endgroup$
    – Brian Hibbert
    Commented Nov 10, 2015 at 14:08

2 Answers 2

Reset to default
7
$\begingroup$

This section of the book appears to be talking about how the details of the threading and scheduling are implemented for a user mode program.

When threading first became popular, most operating systems were Multi-processing OS's, but not "multithreaded" in the sense that the operating system provide support for multiple user code streams sharing the same user address space and allowing these threads to be scheduled separately by the OS. Threading was a concept not dealt with by the OS at all. The OS knew processes, what the processes did with the user mode time they were given was their business.

With User mode threading, support for threads was provided by a programming library and the thread scheduler was a subroutine in the user program itself. The operating system would schedule the process to run and the process would schedule the threads within it. There were problems with this model because an event on one thread that caused the OS to block the process effectively blocked all threads within that process. This model only allowed the threads to run on a single CPU at a time, limiting parallelism. This is the many to one mapping model listed in the book. The single Kernel thread is the user process that the kernel schedules.

With Kernel threads, the OS becomes aware of the threads as separate schedulable entities that share the same address space. The OS can then allow each thread to compete for CPU time separately with other threads in the system. This allows the OS to schedule multiple threads from the same process on multiple CPUs at the same time. It also allows it run threads from a process where one thread is blocked, but the others have computable work to do. In this case each user thread has a backing Kernel thread that is a schedulable entity.

The MUST relationship they are talking about is that even if you are using User threads there is an underlying Kernel thread that the OS can schedule. There MUST be a schedulable entity even if it's at the process level. So your first comment is correct.

Improve this answer
$\endgroup$
1
$\begingroup$

There by no means must be. I have devised and written an OS that lacks said distinction. User threads have no correspondence to kernel threads at all. Executing a system call is always asynchronous; the user thread continues in user code and picks up the result when it is ready and the thread feels like it.

Improve this answer
$\endgroup$

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.