Friday, January 26, 2024

Mission Impossible: concurrent multitasking for individuals

 

    There is always a temptation to try to work on more than one thing at a time. Back in the long ago, it might take a half hour or more for a compilation of a program to complete. During that time, one did something else -- possibly even something useful (isn't playing games useful?). But that was not truly multitasking. I was either working on the program, submitting it, playing games, or testing the program after it completed compilation. Compiling was a background task with which there was no active effort.

     It is certainly possible to work on more than one thing at a time if you have a group of people. One plus one does not quite equal two -- but it certainly allows more to be done. Reduction of need to interact helps the efficiency (but not necessarily the quality). As is seen in "The Mythical Man Month", projects can easily reach a size and complexity such that adding additional people is counter-productive. Teams can still add productivity if each task is delineated sufficiently. Consider a building crew for a house. Two people working together on framing, one person doing insulation, one person doing materials preparation. When tasks can be cleanly split, productivity from multitasking reaches its best -- but each person (or "processor") is working as an individual unit.

     As implied, a computer can make use of multiple processors -- or cores -- to allow simultaneous task performance. Four core, six core, eight core (usually in multiples of two -- does anyone know why?). Once again, the scheduling of software being performed must be coordinated between the cores.

     This blog, however, is primarily aimed at multitasking for individuals (or, more properly, the inability for a person to multitask). It may be easier to explain this by going outside of ourselves and use the single processor system as an example. A processor is moving along, performing the actions required by a particular program. Then, for whatever reason (operating systems, timers, and scheduling algorithms are not current topics), another program needs to be performed. The processor (actually part of yet another program called the operating system -- or done explicitly by each program) needs to "write down" current "context". This context is an image of the current situation at the time of moving to the other program. What is the next line of code to be executed, what are all current (temporary and permanent) results from the program -- all these need to be written down so that, when processing resumes on the current program, it can continue as if nothing had ever interrupted.

     This process -- context switching -- has a certain fixed amount of time needed. So, if you are doing two programs in "multitasking" (true but not concurrent) then there will be time in program one, time to store context, time in program two, store context, restore program one context, time in program one, ... The more often that programs need to swap with each other, the greater the percentage overhead -- this infers that the more programs being swapped between, the smaller active time available per task and the greater percentage overhead.  For example, if dividing up 150 secs of activity between two tasks:

2 tasks present; 75 secs task 1, 25 secs save and swap, 75 secs task2, 25 secs save/swap: 25% overhead

10 tasks present; 15 secs task 1, 25 secs save/swap, 15 secs task2, 25 secs save/swap, 15 secs task3,
25 secs save/swap, 25 secs save/swap, 15 secs task4, 25 secs save/swap, ... : 25/40 = 62.5% overhead

These numbers are greatly simplified (probably would be using nanoseconds, for example) but the principle holds -- the more tasks, the greater the overhead. Note that storage and retrieval of context requires space in addition to time. Too many tasks, too little resources and you have a system unable to do useful work.

     Although there appears to be some similarities between computers and the way humans process information (after all, we did design them) -- we are not the same. We probably do processes much differently than a computer. But the effects can be the same.

     Note that humans are able to walk and chew gum. We can listen to music while writing a letter. This is because different activities use different parts of the brain. In this manner, we have the equivalent of multiple processors -- however, these are not separate general processors -- they are very task-specific processors.

     We can only do one similar category of thing at a time. We can have laundry washing in the background, or a loaf of bread in the oven but those are not tasks in which we are currently active (once we reach the point of taking the laundry out, we are now active again). When we change tasks, we need to keep track of "just what we were doing" at the point of time we changed tasks in order to resume a task. The more tasks we switch between, the less time we have to do each task because of overhead.

     How do we save the context when changing tasks? The process is a statistical curve (maybe not quite a standard bell curve but still ...). When we are young and we get distracted, we may never get back to the original task (which might be the point of the distraction). As we get older, we learn to store context in medium-term memory (maybe jot a short note in addition) and get back to the original. We get "better" at doing more and more tasks -- but we are still decreasing efficiency with each additional task. At some point, we lose context. We cannot remember well enough to resume a task or a set of tasks. We can start recording the context more fully on paper but then we have to file and retrieve that piece of paper.

     From my 66-year-old point-of-view, that is a problem that gets worse with age. Short and medium-term memory gets more clogged with past events/contexts/swaps and we are less efficient at storing and retrieving those contexts. "Why did I go into the kitchen? Where did I put my keys when my son called asking what was for dinner?" At first it is irritating and then, with active understanding, it becomes humorous. I have learned that not everything MUST be remembered -- and that has reduced stress. But it will probably get worse.

     But I am in good company as the ability to task swap is a matter of degree but the challenges exist for all.

No comments:

User Interfaces: When and Who should be designing them and why?

     I am striving to move over from blogs to subscription Substack newsletters. If you have interest in my meanderings please feel free to ...