How are user-level threads better than a sequential process?

What is the use of user-level threads? I read articles saying user-level threads are faster than kernel-level threads. User-level threads are not proactive, and blocking one user-level thread blocks all other user-level threads in the process.

This means that there cannot be a situation where one user-level thread performs IO and another user-level thread is executed. In addition, since the user-level thread provides control, the user-level threads cannot be used for graphical interfaces either.

Question: How are user-level threads better than a sequential process?

+4
source share
2 answers

Typically, you use user-level threads with an event loop, so other user-level threads can continue to execute while someone is waiting for data: the thread scheduler checks the registered file descriptors for readiness when the stream gives, and usually the thread (s) takes precedence for whose input is ready. Meanwhile, non-automatic profitability has a big advantage: you often don’t have to worry about concurrent access to data structures (if the programmer is not stupid and donates in the middle of what should be an atomic operation with respect to other threads). This means less need (often not necessary) for synchronization and blocking, so user-level threads often benefit from kernel threads: much less overhead. And when synchronization is required, it is often cheaper than using kernel threads.

+3
source

One possible benefit: code design / organization. Using the Thread construct, we clearly define the independent processing fragments and the places where they should interact.

+2
source

Source: https://habr.com/ru/post/1344229/


All Articles