What happened when the computer crashed?

Take a few minutes today to share with you a very interesting and knowledge-enhancing question: what are you doing when your computer freezes?

The computer crashes, everyone who has access to the computer should have experienced it.

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 can come as promised, even if you press CTRL+ALT+DELETE on the keyboard to rot,The task manager can't come out either, and in the end, I can only silently press and hold the shutdown button with tears in my eyes to force the shutdown.

So, have you ever wondered what the hell is going on when your computer freezes?

As we all know, the core of a computer is the central processing unit (CPU).Students who have taken computer basic courses have been taught that the CPU is a brainless brain, and it only knows to continuously fetch instructions to execute one by one until it shuts down.

So theoretically, there are two types of crashes. One is that the CPU has stopped working, and the next instruction is no longer executed. This is a hardware crash, but this situation basically does not happen.

It is more of a crash at the software level, that is, the CPU is stuck somewhere and can't get out, resulting in the program that should be executed not being executed, which seems to be a crash.

You may think that if you are smart, if you write an infinite loop and trap the CPU in it and can't get out, will it crash?For example:

void dead_loop() {
  while (1) {
    ...
  }
}

You can try it, and you will find that the fan cooling the CPU may spin up, but the computer will still work normally and not freeze.

An infinite loop, shouldn't the CPU keep spinning here?Wouldn't it crash?

This has to mention a concept: Interruption.

Break

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

Interrupt, as the name implies, is used to interrupt the normal work of the CPU, allowing it to execute the instruction program elsewhere.

The reason why the operating system can control the overall situation is due to a series of interrupt handling functions (such as our most common clock interrupt) that are inserted into the CPU when it starts, so that the operating system can periodically withdraw the execution of the CPURight to schedule other threads to execute.

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

If you want to use an infinite loop to kill the computer, it is naturally impossible.

Actually, I think about it too. If it crashes you so easily, then this operating system is too bad. If a novice is just learning programming, it is not necessary to force restart the computer more than ten times a day?

Ten thousand steps back, even if the impact of interrupts is not considered, most of the current CPUs are multi-core, one thread enters an infinite loop, but there are other cores that can participate in the system scheduling, and still will not crash.

So back to the question at the beginning, where is the CPU stuck and can't get out, and even interrupts can't do anything about it?

There are actually two situations:

1. Interrupt really has no way to take it

Many people know the concept of interrupts, but many people don't know that interrupts also have priorities.

This is easy to understand, such as the CPU is executing a program, and suddenly an interrupt event occurs.The CPU saves the current execution context and turns around to process the interrupt event, but just halfway through the process, a new interrupt event comes, what should the CPU do?Do you want to respond?

So interrupts also have priorities, and low-priority interrupts cannot interrupt high-priority interrupts.

With this premise, imagine what would happen if the operating system's kernel code was improperly written and fell into an infinite loop when processing an interrupt, such as a spin lock?

Because when processing interrupts, the CPU runs at a very high priority, and general interrupts cannot grab the execution right, which leads to the CPU core becoming a "vegetative person", no matter how you call itNo response.

2. The interrupt can grab the CPU, but it is found that no thread can be scheduled

Programmers should not be unfamiliar with the concept of deadlock. Two threads A wait for B, B waits for A, and the two threads wait for each other to make concessions (release locks), forming a deadlock situation and finally becoming a deadlock.

If the deadlock occurs at the application level, it is not a big problem, at most two programs die.But what if it happens in the kernel?

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

Quoting a description of another great god Tim Chen (I think it is very image):