Differences between Multi-threading Models

Question

1. Many-to-One Model
2. One-to-One Model
3. Many-to-Many Model

Advantages and disadvantages of each model ?

Can you give an example ?

EDIT:

One thing is confusing me with the Many-to-One Model I'm quoting the book:

"Thread management is done by the thread library in user space, so it is efficient; but the entire process will block if a thread makes a blocking system call. Also, because only one thread can access the kernel at a time, multiple threads are unable to run in parallel on multiprocessors"

Does it mean all processes in kernel will be blocked, due to the fact that the swapping is done by the application, not by OS scheduler. (since in this model we manage threads in user-mode) ? Or, only the threads belonging to the same process of the thread that made the blocking system call will be blocked ?

Thanks in advance!

Answer 1

We have to assign user level threads to kernel level threads, based on the this the mapping can be:

1. One to one (One user thread mapped to one kernel level thread)

2. Many to one(Many User level threads mapped to one kernel level thread)

3. Many to many(Many User level threads mapped to many kernel level threads)

Here the number of kernel level threads are generally set to lesser than number of user level thread, since management of kernel level threads is much more expensive since it involves kernel intervention in their(kernel level thread's) management.

Because of this reason only the fourth mapping of "one to many"(one user level thread to multiple kernel level threads) to one does not make sense.

"Thread management is done by the thread library in user space, so it is efficient; but the entire process will block if a thread makes a blocking system call. Also, because only one thread can access the kernel at a time, multiple threads are unable to run in parallel on multiprocessors"

this example may help to understand this line:

Does it mean all processes in kernel will be blocked, due to the fact that the swapping is done by the application, not by OS scheduler. (since in this model we manage threads in user-mode) ? Or, only the threads belonging to the same process of the thread that made the blocking system call will be blocked ?

One process's threads are independent of other process's threads.So only the threads belonging to the same process of the thread that made the blocking system call will be blocked.

I hope this does make sense to you...

Answer 2

I can see your problem. You have a horrible book.

You're asking about a couple of related issues. First of all, there are two general ways to implement threads.

1) Threads are implemented in a library using timers. In systems that schedule processes for execution this is the only way to do thread. This was ONLY way to do threads in the olde days. This system is usually called "user threads." User threads are multiplexed within a process. The process does the scheduling of its own threads.

The mythical advantage of "user threads" over "kernel threads" (below) is that they are more efficient. This is what your quoted passage is referring to. The statement "the entire process will block if a thread makes a blocking system call" is only true on some [unix] systems.

2) Threads are implemented in the operating system. A process consists of an address space and one or more threads. The operating system kernel schedules THREADS for execution rather than PROCESSES. These are kernel thread.

Note that even if the system supports kernel threads, it is possible for a process to use user threads. The two are not mutually exclusive. However, a system that does not natively support kernel threads can only use user thread.

That's the simple way to explain the different threading models.

-=-=-=-=-=-=-=-=-=-=-=-

The one-to-one, many-to-one, and many-to-many models are a needless confusion for students. Now we have to get into overlapping terminology.

Let's change the terminology around. For #1, instead of calling the schedulable unit of execution a "process" we call it a "kernel thread." There can only be one kernel thread per process in this model. Then the threads in the process are are "user threads." Any number of user threads execute within/are mapped to a kernel thread. This is then the many-to-one model. User threads = many-to-one.

If we have the operating system create the thread (a kernel thread), let's theoretically call what is being executed a "user thread." Each user thread maps to/executed in one and only one kernel thread. This is then the one-to-one model.

The many-to-one model is the same as what is normally called "user threading model."

The terminology is starting to get nonsensical because there is only one thread but we are calling it a user thread mapped to a kernel thread.

The one-to-one model is what is normally called the kernel threading model.

Lastly, we get to the many-to-many model. It is theoretical BS. In theory, there could be many user threads mapped to many kernel threads. In other words, a single user thread could execute within different kernel threads. I have never heard of system implementing threads this way and I cannot imagine any practicable advantage of such a system.

-=-=-=-=-=-=-=-=-=-=-=-=-

As to your last question, in some operating systems, blocking system calls block also block the timers used to implement user threads (a/k/a many-to-one). If one thread make blocking call, it blocks all the other threads in the PROCESS from executing until the blocking call completes.

This blocking does not occur in all systems (something an OS textbook should point out).