Shulou(Shulou.com)11/24 Report--

This article comes from the official account of Wechat: programming Technology Universe (ID:xuanyuancoding), author: Xuanyuan Wind O

Hello, everyone. I'm Xuanyuan.

Take a few minutes today to share with you an interesting and knowledgeable question: what on earth were you doing when the computer crashed?

The computer crashes, which should be experienced by every friend who comes into contact with the computer.

Especially in the early years, when the computer configuration was not as high as it is now, open a few more heavyweight applications, and the crash would come as promised. Even if you pressed the CTRL+ALT+DELETE on the keyboard, the task manager could not come out. In the end, you could only press the shutdown button in tears and force it to shut down.

So, have you ever wondered what the computer was doing when it crashed?

As we all know, the core of the computer is the central processing unit CPU. Students who have taken the basic computer course have been taught that CPU is stubborn and only knows how to take out instructions and execute them one by one until the computer is turned off.

So in theory, there are two kinds of crashes, one is that the CPU strikes out and no longer executes the next instruction, which is a hardware crash, but this basically won't happen.

More is the software level crash, that is, CPU is trapped somewhere can not get out, resulting in the execution of the program can not be executed, it seems to be a general crash.

Smart you may immediately think, if you write an endless loop, trapped in the CPU can not get out, will not be able to crash? Like this:

Void dead_loop () {while (1) {...}} you can try it and you will find that the fan cooling the CPU may turn on, but the computer still works properly and does not crash.

Endless cycle, shouldn't CPU be circling around here all the time? Won't it crash?

This has to mention a concept: interruption.

The concept of interruption is definitely one of the greatest inventions in the history of computers.

Interrupts, as the name implies, are used to interrupt the normal operation of CPU, allowing it to execute instructions elsewhere.

The reason why the operating system can control the overall situation is that it installs a series of interrupt handling functions (such as our most common clock interrupts) to CPU when it starts, so that the operating system can periodically take back the execution power of CPU and schedule other threads to execute.

So, even if one of your threads enters an endless loop, after your time slice runs out, you have to hand over the CPU and let other programs execute.

It is naturally impossible to crash the computer if you want to use an endless loop.

In fact, I think so, if it is so easy to kill you, then this operating system is too lame, if the novice has just learned to program, do not have to restart the computer more than a dozen times a day?

To say the least, even without considering the impact of interrupts, today's CPU is mostly multi-core, and a thread enters a dead loop, but there are other cores that can participate in system scheduling and still will not crash.

So back to the beginning question, where is CPU trapped and can't get out, and there's nothing you can do to interrupt it?

In fact, there are two situations:

1. Interrupts really have no way to handle it. Many people know the concept of interrupts, but many people don't know that interrupts also have priority.

This is easy to understand, such as when CPU is executing a program and suddenly an interrupt event occurs. CPU saves the context of the current execution and turns around to deal with the interrupt event, but in the middle of processing, there is a new interrupt event coming, what about CPU? Do you want to respond?

Therefore, interrupts can also be divided into priorities, and low-priority interrupts cannot interrupt high-priority interrupts.

With this premise, imagine what happens if you fall into a dead loop when handling an interrupt, such as a spin lock, because the operating system kernel code is improperly written.

Because when dealing with interrupts, CPU runs on a high priority, and general interrupts cannot seize the power of execution, which causes the CPU core to become a "vegetative" and does not respond no matter how it is called.

2. Interrupts can grab CPU, but it is found that there is no thread to schedule programmers to be familiar with the concept of deadlock. Two threads A wait for BMagee B to wait A, and two threads wait for each other to make concessions (release locks), resulting in a deadlock.

If the deadlock occurs at the application level, it's not a big problem, and at most two programs are dead. But what if it happens in the kernel?

For example, in the Windows operating system kernel, there are a large number of global locks, one accidentally causes a deadlock, and other desired threads have to enter the waiting queue, which is cool.

To quote a description of another great god, Tim Chen (I think it's a special image):

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.