I used Python to try to detect keyboard events by placing an pygame function Event.get () in the while loop, with the result that the CPU always consumes 100%. But the operating system and other languages (such as C #) the event listener function basically does not account for the CPU, how do they do? Is it sacrificing the real-time nature of the incident response?
Reply content:
The operating system's event monitoring is done in collaboration with the CPU, a mechanism called
Hardware Interrupts(Interrupt).
Under normal circumstances, the CPU follows its internal program counter (Programs counter
) refers to the directive (instruction
), or if the instruction being referred to is a jump class instruction, such as
x86Class of
PagerOr
JMP,Jump to the point where the instruction is to continue the sequential execution.
In only four cases, the CPU is not executed sequentially, including the above mentioned hardware interrupt, Trap (computing)
), Fault, and abort.
When the hardware is interrupted, the CPU turns to the hardware interrupt handler. The trap is x86.
INTCommand trigger, which is a kernel system call
Implementation mechanism, which causes the CPU to jump to the operating system kernel's system functions (Exception Table). Fault is the exception of 0 error, Page fault
), and even the memory-protection error implementation relies on.
Not sequential execution means that the CPU will immediately drop the instructions at hand to deal with these four cases, after the four cases are processed and then rely on the CPU to jump back to just the instructions to continue processing. That's why even if a single-core CPU takes up another process task at 100%, you can stop the CPU when the keyboard event occurs and run your process as long as your process priority is high enough.
Why listen to keyboard events can not account for 100%cpu, or even 0 of the CPU to occupy it? Because the state of the instruction is not executed even when the CPU is completely stopped (Idle (CPU)
), the hardware interrupt will still start the CPU Start execution Interrupt handler function (Interrupt handler
)。
In particular, when you press CTRL + C, the keyboard hardware will give the CPU a hardware interrupt, which contains an exception number (Exception numbers), and the CPU gets this exception number immediately before it is called by the operating system kernel (Kernel (operating system)
), the interrupt handler function calls the keyboard driver in the kernel, and the keyboard driver invokes the display terminal (computer terminal
) driver displays "^c" on the terminal, while the scheduler wakes up the associated process (computing)
)。 *nix also generates a signal (Unix signal
) is sent to the current process group
), these processes will execute
SIGINTSignal processing function, our CPU is Kernel from the kernel mode
(User mode)
)。
If your process uses a blocking (Blocking) Wait keyboard response before this event occurs, and the user does not have any program execution. Then most of the CPU will be in the kernel code
HLTThe instruction goes to the idle state and is only periodically awakened by the clock's hardware interrupt to see if the scheduler has anything to do. When the keyboard time occurs, your process is awakened, returned from the wait function, and the code continues to execute. You will also see on the computer screen that the CPU is still 0 occupied.
Reference: Computer systems:a Programmer ' s Perspective (3rd Edition)
This problem involves two ways of dealing with events in the system, let me organize the language. One is interrupt, which is the interrupt mechanism of the CPU to remind the operating system what is happening, and the other requires the active pollingof the operating system to check whether an application has an event. The operating system typically provides services to the application through a CPU interrupt mechanism, which is obvious because the operating system uses the second method to keep up with CPU resources to check for events. And the second method is poor in real time. Imagine that the user program to be a timer interrupt to enter the kernel, and then kernel to deal with some tasks after the state of poll all processes, the middle of the latency is certainly more than the direct trigger interrupt.
There are 4 CPU interrupt mechanisms,trap, fault, interrupt, abort. There is a very subtle difference between them. These four kinds of interrupts can be divided into two major categories, one is synchronous, including traps, fault, abort, collectively referred to as exception. The other is the asynchronous occurrence of interrupt. Traps are a mechanism for applications to proactively request services from the system, and Syscall is one of the implementations, so we usually say a user process traps into kernel. Abort means that the execution of the program has been unexpected, and it is often impossible to resume execution, such as a hardware error. Fault also refers to some of the exceptions in program execution, but it is usually possible to resume execution, such as page fault. Finally interrupt is usually triggered by external input hardware interrupt, keyboard, mouse, touch screen, timer and so on belong to this. A more detailed explanation of this can be found in section 8.1 of Csapp's second edition.
To describe why the system listens to keyboard events with little or no CPU resources, it is important to explain how a computer system handles external interrupt. Let's say we run a program in the shell and then press CTRL + C to exit. First, when we press CTRL +C, the keyboard controller initiates a interrupt and forwards it to the CPU. The CPU will automatically trigger interrupt by looking at its own IDT (Interrupt descriptor table) to find the HANDLER,CPU keyboard corresponding to keyboard interrupt The interrupt process (shell) stack pointer, instruction pointer, etc. are push onto the kernel stack and then go to kernel stack and the interrupt that was previously found Handler begins execution. Kernel will continue to push the register value of all remaining interrupts to the kernel stack to form a trapframe to recover the execution shell after processing the interrupt. The kernel then selects a interrupt handler that is encapsulated inside kernel based on the interrupt information given by the CPU to continue execution. The interrupt handler will get the shell's context and then send an INT signal to the shell and resume execution of the shell. The shell receives this signal and then goes to its own INT signal handler to continue execution. The handler then calls a system call kill to close the child process that runs on foreground (the process using the keyboard must run on the foreground), and then waits for the user to enter the next command. At this point the hardware + operating system +shell to work with each other to process a keyboard input process is over. This procedure omits thousands of characters =,=. It seems tedious, but the system is like this, ensuring that hardware resources are shared while maximizing efficiency, and that there are adequate protection mechanisms =,=
EDIT: The second paragraph has been modified to explain the concepts of the four interrupt mechanisms more precisely. But these terms are not entirely unified. I feel that for some kind of interruption, such as page fault, external interrupt, Syscall, divide by zero, it's okay to understand how kernel is handled, without worrying about the details of the terminology.
Because the function you call is not blocked, and there is no wait, it will be full CPU.
If polled, insert a wait in the loop (sleep is one), in other words, let the CPU rest.
If a poll takes 0.1 milliseconds and an increase of 10 milliseconds to wait, the CPU will take 0.1 milliseconds to rest for 10 milliseconds, so the CPU consumption drops to 1%.
The above is a very intuitive explanation. Polling or interrupts can be packaged as blocking calls, that is, you don't have to deal with the problem of how to get the CPU to rest, and when there is no message, it blocks the rest of the function, and when the function returns, it is sure to return the result. If the function you're using is blocked by itself, you don't have to worry about CPU usage.
Blocking calls solves the problem of CPU full load because the internal already contains the operations that make the CPU rest relevant.
However, blocking calls have created a new problem: How can I query multiple different messages at the same time? How do I poll for multiple different things at once?
So you stumbled across the core of asynchronous communication. To put it simply, it is generally in a function to listen to multiple sources at the same time, any kind of message comes back to you. If the function is blocked, it must return a message.
But sometimes you want to add a little bit of Sihuo in addition to the message, so the function does not block, in which case you still need to wait in the loop to avoid CPU load.
The asynchronous event processing mechanism has become the mainstream of modern server programming, because only the asynchronous processing mechanism can deal with the large number of requests in a short time and do not use excessive resources, multi-threaded/multi-process mechanism can not be done.
Word: Non-blocking polling, please wait. Do not want to wait, use a blocking call. Multiple events are polled at the same time, using an asynchronous event-handling mechanism. There are two ways to monitor a person's whereabouts:
1. Do not let him know that you stare at him all the time, it will fill you up, but there is no impact on him, this is called polling
2. Tell him that you are watching him and telling you when he does what you care about, which doesn't take up much of your time, but there's a lot of trouble for him, it's called interrupting my last job. My team leader not only deals with this group, but also responds to the needs of other groups. This is the background.
At first, everyone was sent an email to communicate. The team leader's work is: to deal with a round of the group of things, check the mail to see from the external needs, have the mail on the processing of the group after the matter, did not directly deal with this group of things. This is called polling.
Suddenly one day the big leader had an emergency to find him, sent him an e-mail. Waited for half an hour to get a response, a delay. The big leader is very angry to train my team leader a meal. He summed up the lesson, found that some things are to respond in a timely manner, so that people may be in urgent need to call later. After receiving the call, he would put down his things and immediately deal with the demand of the telephone, and finish the work before it. This is called interruption.
Then one day, HR gave him a call, he went to HR that receive the material processing finished and handed over to HR. He went to the end of his fart to get the material processed, and then to the HR was told that in fact, within three days will be OK. He thought carefully, some things started very urgent, such as the collar, the back is not so urgent and quite troublesome. When he received some calls, he immediately finished the first half, then dropped them and took the time to deal with them. This is called a hard interrupt and a soft interrupt separation.
And then ... The company's express too much, the big leader let him receive all the courier. So he received a day of countless express small brother dozen phone calls. Tired to death. This is called interrupting the storm.
So the next day he gave the doorman uncle to say hello, let Grandpa staged Express, the first express to give him a call, he interrupted the upper half of this thing down. Don't bother him if you don't have a courier all day. He picked up a day's courier from the porter at the end of his work. This is called in the soft interrupt polling processing.
So the master, as written above, interrupts in a busy time to be more responsive than polling. And what you do is let me so smart leader busy time, to the mailbox constantly press refresh ... Yes, the real-time nature of event handling was sacrificed. The other two answers say yes, event detection is by polling or interruption. Let me explain why your code consumes 100%CPU:
As an example of CPU usage in the win Task manager, we know that Windows relies on assigning time slices to each thread to implement multi-threaded/process, each time slice is about a few milliseconds to more than 10 milliseconds. The WIN8 Task Manager draws the CPU usage curve by default at a rate of 1 seconds and 1, which is how much of the percentage time in the past 1000ms has been used in addition to the system idle process. Your python uses a while loop, which causes the thread to always use the allotted time slice, so the CPU usage will be 100%. In fact, you just add a time.sleep (0.001) to the while and the CPU is lowered.
The Sleep function tells the operating system that this thread will discard the current unused time slices and not allocate time slices to me for the next specified time. In fact, the entire operating system process in the vast majority of the time, are waiting for sleep, the other will check the user input, message delivery and other events occur, so the CPU usage is not high. The more sleep you have, the lower the CPU utilization per unit time. There are two ways to listen for an event, one is polling, the other is a break, the second is in a Windows environment, or it can be called a hook (don't be too tangled in what you call, understand it).
Polling is the way you write in Python,
a while constant check, keep asking: happened no, happened no......
What does the hook mean? In a Windows environment, any event is sent to all windows in the form of an event broadcast, the window receives the event and then handles it, and for a key (keyboard) event, the approximate flow is this (xp-win7 ERA process):
1) Hardware interrupt/Hardware port data
Winio can simulate, or modify, IDT is at this level
2) keyboard port driver (USB or PS/2)
The filter driver is in this
Keyboardclassservicecallback is also called on this layer
3) Kbdclass Drive
Working with keyboard layouts and keyboard languages, some high-end viruses also work here
4) Windows kernel boundary (zwcreate/zwreadfile)
----------------------(System call)----------------------
5) Windows kernel boundary (zwcreate/zwreadfile)
6) Csrss.exe's win32k! Rawinputthread read, complete conversion of Scancode and VK
//setwindowhook work here (global)
Kbd_event's working here.
7) Csrss.exe calls DispatchMessage and other functions to distribute the message (
Start broadcasting keyboard messages here）
Setwindowhook work here (process)
PostMessage and SendMessage are here.
8) processing messages for each process (window thread)
In the 6th step, if you hang a hook, then theoretically all the regular key messages can be received, when there is no key message is the time, the hook function is not called and executed, so it will certainly not occupy the CPU.
The same applies to other hooks:
The event did not occur and the hook was not executed, so it does not account for CPU。 Don ' t call me, I'll call you .... To add, the fact that the interruption is necessary, but not sufficient. Imagine that the CPU is still running, except that the clock does not have any interrupt source occurrences. The difference is that it can be set to a low-power state at this time. Think of the previous microcontroller inside the timer delay and hard code delay
