It should not be surprising that there are many aspects of computer architecture which mirror how humans think and behave. Humans designed computers. Humans developed programming. Humans devise algorithms. Is there any way that the patterns of thinking and behavior for people could NOT have influenced the design of computer systems?
Sometimes, you want to do multiple things "at the same time" or you want multiple programs to run "at the same time". As discussed in my blog on multitasking, this isn't really possible but, on a computer, it is possible to make it LOOK like it is doing multiple things at the same time. The computer can produce this illusion because of how quickly it can follow instructions. The speed at which it changes back and forth between programs is quick enough that humans cannot perceive the difference. It is different with humans -- the swapping of tasks is very noticeable and humans are not as good at it as computers.
Sometimes it is possible to want to do one thing most of the time but, occasionally, need to do something else. Sometimes that "something else" is only ready to be done at unknown times. Sometimes that "something else" is just of lower priority than your main task but you still want to have it done when possible.
This latter situation is usually done on computers by means of the operating system (Windows, iOS, Linux, ...) and using priorities of tasks as a criterion for when programs, or tasks, are scheduled to run. In the world of the human, it is an organization matter. It is still most efficient to continue on one task to completion and then change to a different task but it is possible to schedule the tasks to take different amounts of the day. You work on cleaning the house for two hours, then you watch your favorite serial streaming program for an hour, then you resume cleaning the house for another two hours, and so forth.
The first situation -- where a secondary task is not always ready to be done -- has a couple of primary ways to be handled. One -- you can check on the readiness of the secondary task every once in a while (either at regular intervals or just "whenever you think about it"). This is called "polling". The other is you have some type of indication that interrupts you and tells you that the secondary task is now ready to be done. That is what doorbells are used for. Rather than checking the front door every few minutes to see if someone is present, you expect them to ring the doorbell when they arrive. (If someone arrives, and you are expecting to hear the doorbell, then there may be a long wait if the doorbell is broken or they don't feel comfortable pushing the button.)
So, when do you do one method and when do you do the other? Polling has the advantage that it is done when you are ready for it (the secondary task may not be ready but you are ready to check). Being ready, you have no additional things to do before you go check the front door. Interrupts (as long as they are reliable to happen) have the advantage in that you go to the secondary task ONLY when it is ready so there is no added inefficiency of checking and having the secondary task not ready.
Sounds as if interrupts are best? Ah, but there are a couple of problems. First, since an interrupt may arrive when you are NOT ready, you have to quickly do whatever you may need to do to become ready before you attend the secondary task (turn off the heat on your cooktop, put the ice cream back into the freezer, put a bookmark into (or within for an ebook) a book you are reading, and so forth). This is "save and restore" (when you leave to get the secondary task and when you return from the secondary task) and it can be significant overhead for being able to handle the interrupt. Second, sometimes it just is NOT a good time to be interrupted. Ever take a good soaking bath and have the doorbell ring? You can disconnect the doorbell before you enter the bathtub but then you risk missing someone arriving. (In the case of computer systems, you may miss some critical thing that MUST be worked with in a certain amount of time -- thus, you never turn off interrupts within a nuclear power console -- you just become ready to go to the control panel in your bath robe.)
The decision as to whether you poll or allow an interrupt to trigger a response depends on many factors. One important one is -- how time critical is the second event? Can the secondary event wait five or ten minutes? Perhaps even a half hour? It is important to reduce the heat under a sauce after it is ready but it may allow five or so minutes leeway. But, if a smoke alarm goes off it is very important to check as to what is wrong very quickly -- if only to silence the alarm. A secondary task that is not time critical is a good candidate for polling (checking every once in a while). The smoke alarm generates its own interrupt in the form of an audible sound. Another factor is "how often is this going to occur?" Remember that unexpected interrupts have an overhead, an extra amount of work needed to prepare to handle the interrupt. If the event happens (and is ready) frequently then polling is a good way to monitor it (because the percentage of times you check and it is ready is a high percentage).
Life will carry on. You will continue to get unexpected interrupts. You will occasionally get back to doing something too late and a pan may burn. But if you understand what is going on and how you can handle it you may be able to organize matters to optimize how you work with those events.
