in reply to Re^3: RFC: Using 'threads' common aspects
in thread RFC: Using 'threads' common aspects
The multiprogramming level, whatever you call it, is “the (maximum...) amount of simultaneous activity that the program in question will attempt.” And that is, the number of threads in the pool.
I'm sorry, but you are so wrong it is hard to know quite where to start correcting you. If your mental model of modern, pre-emptive, multi-tasking, multi-threading OSs, is the long abandoned early attempts at multiprogramming from the 1960s, it becomes clear why many of your other wisdoms on threading are so far off base.
There were no threads, and nothing simultaneous. Nothing pre-emptive; nor even cooperative. The multi-programming level controlled the number of tasks that were held in memory, and that is it. The idea was that when (if) one of those tasks did some peripheral IO, then control could be transferred to one of the other memory resident tasks. But if a task did no IO, then the other tasks never got a look in until the first finished. The aim was simply to improve CPU utilisation, nothing more.
May be this will clarify things for you.
There is an extremely tenuous analogy between MPL and the thread pool model, but it is as between a modern, grid-synchronised, computer-controlled traffic lights network, and a policeman on a box waving his arms around.
|
|---|