Wednesday, October 26, 2011

Pop Your Stack

A commonly used and misunderstood concept purloined from computer science is "multitasking". We often apply it to someone who insists on being able to do many things simultaneously. Thing is, computers don't actually do more than one thing at a time and, if you've ever had a conversation with a multitasker, you'll have noticed that neither do people.

In the early days of computing, you know, like the 60's, computers ran what were called "batch" jobs; each computer ran just one program at a time. The program ran from start to finish. If you wanted to run your program, you would schedule time on the computer. At your allotted time, you load your program; it runs.

If there's an error in your program, it stops. You go back to your office and try to figure out why. You fix it and schedule more time.

In the late 50's and early 60's people started to wonder if there wasn't a better way. Would it be possible to create an operating system that would allow a computer to automatically schedule jobs and run them? Further, since much of the computer's processor time is spent waiting for things like input from a keyboard or something retrieved from a disk, why couldn't the computer do something else while it was waiting?

Researchers began working on systems that could schedule jobs themselves and reallocate resources from jobs that didn't need them to jobs that did, systems that could manage multiple jobs or tasks on their own. In 1965, what may be the first such system, MULTICS (Multiplexed Information and Computing Service), was born. It was followed by systems such as VMS, UNIX and PL/1.

Multitasking systems don't actually perform multiple tasks at the same time. Instead, they switch from task to task so quickly that they appear to be doing many things simultaneously. It's like watching a fan blade spin; the blade is only ever in one place, but it appears to be simultaneously everywhere.

What determines when to switch from one task to another? At the heart of a multitasking system is a "scheduler". The scheduler allocates resources to various tasks based upon need and availability or time allocation. If a resource frees up, the scheduler allocates it to another task. If a task has used up its allotted time, the scheduler stops it, and starts another task. If an important event requires immediate attention, the scheduler interrupts whatever task was running and addresses the event.

The critical step in all this working is known as a "context switch". The scheduler can't simply stop one task and start another. If it did, then the first task would have to start over again each time it was reallocated resources. So before switching from one task to another the scheduler must store away all the information required to restart the first task at the same point; this information is collectively called the task's "state".

The scheduler sees that it's time to switch tasks. It stops the first task, cobbles up its state information and stores it. It retrieves the second task's stored state information, loads it and starts the second task.

Most multitasking operating systems simultaneously run tens or even hundreds of tasks. That's a lot of state memorization and context switching.

Most humans don't recognize these requirements for true multitasking. Many simply don't store or recall the state: Where was I now? What were we talking about? What's your name again? Why did I walk into the kitchen? Even when we do, we're often not that quick at context switching: Maybe if I retrace my steps, I'll remember. Wait, don't tell me, ummm, your name is... OK, now I remember, we were discussing...

Without these two capabilities, you can't multitask, or at least not well. The response of many to "human-multitasking" is that it doesn't work. I would rephrase that to say that almost no one does it well. Nonetheless, it can be learned. The trick is to be completely present with the task at hand and then to switch from task to task deliberately making sure to note where you were when the switch occurred. If you become good at this, you can become a good multitasker; if not, you're just kidding yourself.

As you become better at multitasking, you'll find yourself able to follow conversational threads as they roll out and to roll them back up to the original thread whenever someone asks, "How did we get here?"

Each conversational thread establishes a new context. As new contexts are created, you throw the previous context on top of the stack of previous contexts and begin a new one. To roll back to the beginning, you just keep pulling contexts off the stack until you've pulled the first one. In computer science, we call this form of context retrieval, popping the stack.

One of my favorite ways to practice context switching is to follow my friend Mark Kaufman in unaided conversation and to see how far afield he can go before I lose the thread. It's amazing how well you can multitask if you're deliberate about it.

Happy Tuesday,
Teflon

No comments:

Post a Comment

Read, smile, think and post a message to let us know how this article inspired you...