OS multitasking in terms of queuing system
I would like to tell a little about the multitasking of the operating system. On the concept of managing processes and threads from the point of view of the OS (and processor / processors) as a queuing system. About how "how it happens."
There are a lot of processes, but resources are limited. All at once is not enough. What to do? And here there is an analogy with a queuing system. You can think of a pool of processes as a queue at the cashier. Oh, sorry, in the processor. And there are three archaic processing options for such a queue [I know].
Initially, I will focus on the fact that the processor is one. To simplify. Then I'll tell you what, in my opinion, the difference.
')
For a start: general information.
Picture processor
What is a “process” and how does it differ from a “flow”? The process is (roughly speaking) - an application for the implementation of something. More precisely, on the consumption of system resources. The OS generates system information, which says what resources the process needs. And also about those resources that he was actually allocated. And this is for each newly created process separately. How much memory he needs, how much CPU time, etc.
So what am I talking about? Oh yes.
Archaic ways to handle the queue, as I said, I know three.
First: quantization.
That is, each process is allocated a certain quantum of time, after which the processor happily reports: “Free cash!”, And receives the following process for servicing. The current process goes to the end of the queue. For "all are equal." Disadvantages: (rough example) you have a video conference. Very important. Right on the most interesting place: broads! And the "important" document is printed. He is a letter asking to postpone the delivery time of the daily lunch from 13:00 to 14:00. And your videoconference "it is not known when" will be resumed. Of course, in practice this does not happen, because the printer works by interruption, and there everything is different. But the analogy, it seems to me, is generally clear.
Second: priorities.
This is when "not everyone is equal." The process is assigned a priority, and until the process with a higher priority is served (oh, sorry, processed), others cannot approach the checkout (oh, sorry, to the processor). Disadvantages: there may be processes that, due to low priority, will never be processed. Ie, the letter you never print.
In practice, the “all are equal, but some more even” approach is often used. Ie, "mixed." When the process is allocated a quantum of time and priority at the same time. Then the process goes not to the end of the queue, but somewhere in “its” middle. And waiting there.
The scheme is clear, but how are the processes handled? In what order? There is still the same queuing system. There are several approaches to processing processes in the case of quantization and the "mixed" type:
- FIFO. The first came, the first came out. (First-In-First-Out)
- LIFO. The last one came, the first one came out. (IMHO, not very honest ...) (Last-In-First-Out)
- SIRO. Well, it's full of random. Service-In-Random-Out.
In the case of "clean" priorities, such questions do not arise, of course.
After all, I promised to share my thoughts on this matter. Well, let's imagine that there are several cash registers (processors). And here the same principles, only a few queues, and processes get in randomly or not very well in the queue (which I think is not very logical, well, for example, if only because the "single processor" systems still work on the new processors) . Or just the queue (the pool from which the processes are taken) is one, and they are processed by several cash registers. But this is only the thoughts of the author, nothing more.
A very reasonable question may arise.
And everything is simple. At the beginning of the article, it was mentioned in passing that the program needed resources and processor time to execute. So, the system "perceives" the process as an application for any kind of resources, except for CPU time. Application for processor time is a thread. It is processor time that is distributed between threads. Thus, the process consists of several threads. Previously, of course, it was all one. And the process, and the flow, and all in one, and in general, "why pay more?". As it turned out, in this case, we rather “pay less”. When there are several threads.
In order that processes could not interfere with the distribution of resources, the system “isolates” them. Provides each of them with their own virtual address space. So no process can get direct access to the commands and data of another process.
When interaction is necessary, processes turn to the OS, literally, as an intermediary. And she already helps them, gives the means of communication.
But between the threads of the same process there is no complete protection. Because it is not only impossible, but nobody needs it. To exchange data streams do not necessarily refer to the OS. They use shared memory. One writes data, the other reads. And everything's good. In addition, threads of different processes are still well protected from each other.
Multiprogramming is more efficient at the level of threads, not processes. Each thread has its own command counter and stack. A task executed in the form of several threads can be performed faster due to parallel (or pseudo-parallel in a single-processor system) execution of its parts.
A process is an application for the consumption of all resources except processor time. Processes are isolated from each other, and includes threads. Actually, threads are applications for the consumption of this very CPU time.
The greatest effect from the introduction of multi-thread processing is achieved in multiprocessor systems, in which the threads (even within a single process) can run in parallel, rather than pseudo .
In addition, the concept of the work of the [mass service] system as such was demonstrated by example.
And ps
I “wore” a little at the beginning and in the middle of the article, talking about processor time for the “process” as such. But not much, and I hope you will forgive me for this forced inaccuracy.
There are a lot of processes, but resources are limited. All at once is not enough. What to do? And here there is an analogy with a queuing system. You can think of a pool of processes as a queue at the cashier. Oh, sorry, in the processor. And there are three archaic processing options for such a queue [I know].
Foreword
Initially, I will focus on the fact that the processor is one. To simplify. Then I'll tell you what, in my opinion, the difference.
')
For a start: general information.
Picture processor
What is a “process” and how does it differ from a “flow”? The process is (roughly speaking) - an application for the implementation of something. More precisely, on the consumption of system resources. The OS generates system information, which says what resources the process needs. And also about those resources that he was actually allocated. And this is for each newly created process separately. How much memory he needs, how much CPU time, etc.
So what am I talking about? Oh yes.
How to handle the process queue
Archaic ways to handle the queue, as I said, I know three.
First: quantization.
That is, each process is allocated a certain quantum of time, after which the processor happily reports: “Free cash!”, And receives the following process for servicing. The current process goes to the end of the queue. For "all are equal." Disadvantages: (rough example) you have a video conference. Very important. Right on the most interesting place: broads! And the "important" document is printed. He is a letter asking to postpone the delivery time of the daily lunch from 13:00 to 14:00. And your videoconference "it is not known when" will be resumed. Of course, in practice this does not happen, because the printer works by interruption, and there everything is different. But the analogy, it seems to me, is generally clear.
Second: priorities.
This is when "not everyone is equal." The process is assigned a priority, and until the process with a higher priority is served (oh, sorry, processed), others cannot approach the checkout (oh, sorry, to the processor). Disadvantages: there may be processes that, due to low priority, will never be processed. Ie, the letter you never print.
In practice, the “all are equal, but some more even” approach is often used. Ie, "mixed." When the process is allocated a quantum of time and priority at the same time. Then the process goes not to the end of the queue, but somewhere in “its” middle. And waiting there.
The scheme is clear, but how are the processes handled? In what order? There is still the same queuing system. There are several approaches to processing processes in the case of quantization and the "mixed" type:
- FIFO. The first came, the first came out. (First-In-First-Out)
- LIFO. The last one came, the first one came out. (IMHO, not very honest ...) (Last-In-First-Out)
- SIRO. Well, it's full of random. Service-In-Random-Out.
In the case of "clean" priorities, such questions do not arise, of course.
And what about multiprocessor systems?
After all, I promised to share my thoughts on this matter. Well, let's imagine that there are several cash registers (processors). And here the same principles, only a few queues, and processes get in randomly or not very well in the queue (which I think is not very logical, well, for example, if only because the "single processor" systems still work on the new processors) . Or just the queue (the pool from which the processes are taken) is one, and they are processed by several cash registers. But this is only the thoughts of the author, nothing more.
A very reasonable question may arise.
But what is the difference between the process and the flow?
And everything is simple. At the beginning of the article, it was mentioned in passing that the program needed resources and processor time to execute. So, the system "perceives" the process as an application for any kind of resources, except for CPU time. Application for processor time is a thread. It is processor time that is distributed between threads. Thus, the process consists of several threads. Previously, of course, it was all one. And the process, and the flow, and all in one, and in general, "why pay more?". As it turned out, in this case, we rather “pay less”. When there are several threads.
In order that processes could not interfere with the distribution of resources, the system “isolates” them. Provides each of them with their own virtual address space. So no process can get direct access to the commands and data of another process.
When interaction is necessary, processes turn to the OS, literally, as an intermediary. And she already helps them, gives the means of communication.
But between the threads of the same process there is no complete protection. Because it is not only impossible, but nobody needs it. To exchange data streams do not necessarily refer to the OS. They use shared memory. One writes data, the other reads. And everything's good. In addition, threads of different processes are still well protected from each other.
Multiprogramming is more efficient at the level of threads, not processes. Each thread has its own command counter and stack. A task executed in the form of several threads can be performed faster due to parallel (or pseudo-parallel in a single-processor system) execution of its parts.
Obvious conclusions
A process is an application for the consumption of all resources except processor time. Processes are isolated from each other, and includes threads. Actually, threads are applications for the consumption of this very CPU time.
The greatest effect from the introduction of multi-thread processing is achieved in multiprocessor systems, in which the threads (even within a single process) can run in parallel, rather than pseudo .
In addition, the concept of the work of the [mass service] system as such was demonstrated by example.
And ps
I “wore” a little at the beginning and in the middle of the article, talking about processor time for the “process” as such. But not much, and I hope you will forgive me for this forced inaccuracy.
Source: https://habr.com/ru/post/87091/
All Articles