一对一多线程模型

Question

In silberschatz "Operating System Concepts" book, section 4.3.2 says that

one-to-one model provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors.

I have two questions here:

1. How can one thread be blocked and other mapped on kernel thread? Dont we know that if one thread is blocked, entire process of that user-level thread is blocked?
2. The OS considers user-level threads as one thread only. It cant be assigned to multiple processors/cores. Isn't the below given line contradicting that idea?

   It also allows multiple threads to run in parallel on multiprocessors

Answer 1

Your understanding of user level threads and kernel level threads is not correct, in particular you need to understand how user level threads are mapped to kernel level threads. So first lets define some terms

Kernel thread

A thread ( schedulable task ) that is created and managed by the kernel. Every kernel level thread is represented by some data structure which contains information related to the thread. In the case of Linux it is task_struct . Kernel threads are the only threads that are considered by the CPU scheduler for scheduling.

Note: Kernel thread is a bit of misnomer as Linux kernel doesn't distinguish between a thread and a process, schedulable task would better describe this entity .

User thread

A thread that is created and managed by some library such as JVM above kernel level. The library that creates these threads is responsible for their management that is which thread runs and when.

User level to kernel level mapping

Now you can create as many user level threads as you want but to execute them you need to create some kernel level thread ( task_struct ). This creation of kernel level threads can be done in many ways

One to one model

In this case whenever you create a user level thread your library asks the kernel to create a new kernel level thread. In the case of Linux your library will use clone system call to create a kernel level thread.

Many to one model

In this case your library creates only one kernel level thread ( task_struct ). No matter how many user level threads you create they all share the same kernel level thread, much like the processes running on a single core CPU. The point to understand is that your library here acts much like the CPU scheduler, it schedules many user level threads on single kernel level thread.

Now to your question

The OS considers user-level threads as one thread only. It can't be assigned to multiple processors/cores. Isn't the below given line contradicting that idea?

If you were using many to one model, in that case you will have only one kernel level thread for all of your user level threads and hence they cannot run on different CPU's.

But if you are using a one to one model then each of your user level threads has a corresponding kernel level thread that can be scheduled individually and hence user level threads can run on different CPU's given that you have more than one CPU.

Answer 2

You are suffering from a confusing book.

There are real threads (aka kernel threads, 1 to 1 model) and there are simulated threads (aka user threads, many to 1 model).

Some books make this more confusing by throwing a hypothetical many to many model.

User threads are obsolete. Any operating system book worth reading these days would treat them that way and describe them in historical terms.

How can one thread be blocked and other mapped on kernel thread? Dont we know that if one thread is blocked, entire process of that user-level thread is blocked?

You either have user threads or kernel thread. An application that did both would be royally screwed up.

The OS considers user-level threads as one thread only. It cant be assigned to multiple processors/cores. Isn't the below given line contradicting that idea?

In ye olde days a process was considered to be an execution stream and an address space. There were no threads. When threads became necessary (largely due to the need for Ada support), they were simulated using timers. The behavior of threads varied by operating system.

In Eunuchs variants, blocking calls block the process entirely. Thus in simulated (user) threads a blocking call in one thread would block all threads. This is not true on all operating systems.

Now, a process is one or more execution streams and an address space. That is what you ought be learning; not a bunch of technobabble.

A book that talks about threads in terms of 1-to-1 or many-to-1 models is only fit to line cat boxes.