Analogy to teach beginners the concept of interrupt

Question

What will be a simple analogy to use in teaching non-CS people the concept of interrupt as part of OS topic?

Answer 1

Classroom activity.

---

A. The prep.

1. Some project requiring a few minutes of the students' time. Writing down definitions from the board, or researching something online. Anything which fits within the normal operations of the class, and requires each student to do their own work and excludes other activities.
   • A useful possibility here would be to create some defined directory structure on their local/lab computer, including starter source files, which will be needed for later code projects. (If the students have workstations and the course will involve code work in the following weeks.)
2. A small project, or a few such, which one student can be asked to do during class. Hand back graded papers, distribute lesson materials, move a table, etc.
3. A tennis ball, ping-pong ball, or Nerf ball. Something light, and safe to use in the classroom. If available, a ball large enough to require both hands to catch would be best.

---

B. The activity

1. At any point during the class period, at the beginning is not required, assign the main task above to the students.
2. At the point when the students should be approximately one-third done with the task, ask one to perform the simple task. If there are multiple simple tasks planned, they can be started in a staggered manner, or they can be performed one at a time. In the case of more than one simple task, allow all but the final one to be completed, and the involved students to return to the originally assigned task.
3. While the final, or only, task is being performed, surprise the student performing it by telling them to "think fast" or "catch this", and toss the ball to them with barely enough time to react.
4. Allow the final simple task to be completed after the ball has been tossed, and allow all the students to complete the main task.
5. Proceed with the lecture, or discussion, on interrupts.

---

C. Taking points

1. While the OS is loaded, the computer is always doing something. Typically the on-screen clock is updated in most windowed environments. Who know what "housekeeping" activities are happening under the hood. If nothing else, the system is looking for further instructions.

   • Prior to the assignment being given, the students were doing something. Thinking about the last class, planning what to do after class, looking at the clock, or, at the very least, waiting for what you would say next.
   • The primary assignment was an example of event-driven operations, where the system is idle until something is requested. The user launches a program, for example. The request is handled, and then the system goes idle again, awaiting another event to respond to.

2. While following instructions, the system is also monitoring other sources of instructions; interrupts. A normal interrupt causes the system to pause one task, at some convenient point, and process the new request. Completion of the new request is followed by resuming the original, or interrupted, task.

   • When asked to perform the simple task, the affected student did not stop immediately and begin the new task. They did not stop writing mid-stroke on a letter, or probably even mid-word, if writing. They did, however, pause the main activity to handle the simple assignment, and returned to complete the main activity once they had accomplished the simple request.
3. Different tasks and interrupts have different priorities, and when, or even if, the system responds to them depends on relative priorities of the task to be interrupted and the interrupt itself.
   • Each student involved did their own scheduling around the simple tasks. Completing a letter, work, line, thought, or sentence was their choice. None of them (hopefully) assigned a low enough priority to the simple task as to complete the main assignment before starting the simple task.
4. In some systems there are interrupts with an assigned priority as to be unavoidable. Factory floor robotics must respond to a safety sensor, for example. The computer might ignore most pressed keys if something is running. CTRL+C is often an exception to that rule. CTRL+ALT+DEL is almost always an exception, in Microsoft Windows anyway. Such interrupts are often called priority interrupts.
   • Catching the ball was not planned by the receiving student, yet the response was instantaneous, even if the ball was dropped.

---

D. Bonuses

1. If there was more than one simple task applied, and two, or more, were being done at the same time, multi-core threading can be discussed.
2. If, when trying to catch the ball, the student dropped the papers, or somehow messed up the task, you can discuss security exploits which operate on exceptions; divide-by-zero errors, segmentation faults, etc.

Answer 2

Fire alarm goes off during exam.

Nasty uncle Ben shows up in the middle of supper.

Tire blows out while driving.

Student raises hand during lecture.

Baby wakes up in the night, screaming.

Anything in general, that happens without warning and that requires attention or action of some kind.

Answer 3

A good analogy would be (sorry, smartphone ringing, i've got to leave)

Answer 4

I would use the example of when one thought runs into another in your head, and two words are interleaved as a result, for example if you're trying to say "awesome" and also "exciting," you'll say "awe -- citing" or "ex -- some." This is because the process of you saying one word has been interrupted by some thought and jumped to saying another word. I think that this is an experience that many people have had, and really accurately gives the feeling of an interrupt, i.e. an immediate involuntary jump to something else.

However, if you're looking for an analogy which will better lead to some kind of project or programming insight, this may not be the best analogy.