In a pure user level thread strategy, why can't a multithreaded application take advantage of multiprocessing?

0
votes

My textbook states the following:

In a pure ULT (user level thread) strategy, a multithreaded application cannot take advantage of multiprocessing. A kernel assigns one process to only one processor at a time. Therefore, only a single thread within a process can execute at a time. In effect, we have application-level multiprogramming within a single process. While this multiprogramming can result in a significant speedup of the application, there are applications that would benefit from the ability to execute portions of code simultaneously.

I understand the elementary concepts, such as user level threads, multithreading, and multiprocessing. However, I don't understand the above justification for why a multithreaded application can't take advantage of multiprocessing in a pure ULT strategy.

I would greatly appreciate it if someone could please take the time to clarify this with a clearer explanation.

1
multithreadingoperating-systemmultiprocessing
It is because kernel is not aware of threading. It only assigns a process to run and its the job of the user-level-library to schedule the threads to run. So if you have a process with 5 threads, they will share the time running on the same CPU. – Tony Tannous

1 Answers

3
votes

The important fact is that user level threads (or green threads) are handled by the programming language and are not exposed to the operating system. In ULT the threads are entirely "hidden within the python runtime". This has the advantage that the programming processing envinroment has the full control over the threads. To the OS the program looks like a single thread and thus only runs on one core at a time.

On the other hand, kernel threads are handled by the OS. They can run on different cores at once and benefit from this speed improvement. The downside is that things like "thread safe memory access" need to be handled by the threads themselves and there is no "outside language scheduler" (as in user level threads) which can guarantee the thread safety. That's why for instance in python there's a "global interpreter lock" which guarantees, that two kernel threads never run at the same time.

That's just a short summary. If you're interested to know more, look up "global interpreter lock" (python, ruby) or see this answer