Interrupt Driven: Design and Alternatives

 

     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.

Multitasking: Can humans really do it?

 

     Let's get more done! Why aren't you multitasking? Have these words ever been said to you? Or have you said them to yourself or others? The idea of multitasking can be very attractive. If you're doing more than one thing at a time then surely you can accomplish more. Right?

     From a computer science point of view -- which is where the concept originated -- multitasking can be a function of the operating system (the software which allows the processor/computer to do different types of programs and activity). Not all operating systems support multitasking but most, in widespread use, do. The operating system is the primary task being run by the processor.

     With a single processor (the hardware which executes the instructions), only one task can be done at any time. Multitasking is the process of the operating system switching between tasks -- preferably at a point where a task can do no more useful work until some other event happens. The switching between tasks is called a "context switch" because the operating system will save/store all necessary information for the original task to continue (later) before starting another task (restoring the information which it stored when last suspended). The more tasks in the list, and the more often they are switched, the greater will be the percentage of overhead created by context switching. It is possible to get to a point where the processor/computer does almost no useful work if it has too many tasks and swaps too often -- this is called "thrashing".

     Humans can, of course, act as a "processor" but they are certainly not computers. Humans can attempt to multitask -- but they have the same limitations of computers -- and more.

     First, as is true for computers, humans can only do a single task at a time. Second, humans also have to do "context switching" to move from one task (which is not yet complete) to another -- but human context switching is much less efficient, and prone to error, than that for a computer. Third, a computer can move between many different tasks and still remain useful -- a human will likely start losing task contexts and forget tasks or not be able to continue them efficiently.

     Today, I was working on a task at the computer -- and I had some bread toasting in the toaster oven. I got absorbed in the task at the computer and, after a while, smelled something burning. Instead of doing two separate tasks properly, one of the tasks ended up with incinerated toast which had to be thrown out (and the windows opened and fan turned on).

     I could have set an alarm to go and check the toast (but I didn't). For an operating system, an alarm is an interrupt event. Alarms may be associated with an event, an outside input, time, or other measurable event. This can allow one task to continue (but not using the processor) unmonitored (like having a sprinkler within a watering system disperse water) while other tasks are done. The interrupt may be set according to a timer, telling the system to turn off the water after a period of time.

     Note that these comments are for a single processor. When there are multiple processors, then "parallel processing" can be done -- which is similar to having a team assigned to the problem and the pursuant needs to coordinate the work between team members. Each processor, or member, can attempt multitasking but humans in teams cannot do multitasking any better than individually.

     Multitasking makes sense for a computer but it does not work well for humans and the limit for the number of possible tasks for a human to switch between is reached very quickly.