Re: [Phys-L] multitasking

[John Denker <jsd@av8n.com>]

Regarding what it says at:
  http://www.npr.org/templates/story/story.php?storyId=95256794

It seems to me that there are some silly word games going on.  The
article says:

> researchers say [multitasking is] still a myth — and they have the data to prove it.

... but then goes on to give examples that must be classified as
multitasking, according to any reasonable definition of the word.
The article also explains why multitasking is important.  It even
explains part of the process, i.e. part of how multitasking is done.

To me, as I explained before, "multitasking" simply means not waiting 
for one task to finish before starting some additional task(s).  Related 
terms include "division of attention" and "context switching".

As explained in the article, a cook in a restaurant definitely needs to 
multitask.  Forsooth, even in the ordinary home kitchen, multitasking is
a big win.  One of my favorite recipes is triple-threaded:  There is (A) 
15 minutes of cooking stuff in the oven plus (B) 15 minutes of cooking 
stuff on the rangetop plus (C) 15 minutes of thawing and chopping ... 
for a total of 15 minutes ... because A, B, and C all happen in parallel.
Each thread involves multiple steps, so multiple context switches are 
required.

Of course /sometimes/ multitasking fails.  The failure symptom is this:
After switching tasks from A to B to C, when you switch back to task A
you have to restart that task from scratch.  In contrast, ideal successful
multitasking means when you switch back to task A, you take up where you
left off.  In between these two extremes there is some modest cost to be
paid each time a context switch is made.  As you get better at multitasking,
the switching-cost gradually goes down.

Let's be clear:  sufficiently rapid, efficient context switching is virtually
indistinguishable from simultaneity.  Timesharing systems have been doing
this for 50 years.  We know how it works.

If you tell me the skillful cook is not really "multitasking" I put that in 
the category of meaningless word-games.  You can call it whatever you like;
I call it multitasking.  I don't need to perform a brain-scan on the cook;
I can objectively count the tasks.  I can objectively measure the latency
and throughput.

Regarding efficiency:  Yes, there is some cost associated with switching
from task to task ... but that doesn't even begin to tell us whether multi-
tasking is more efficient or less efficient.  More or less compared to what?
I guarantee you that in a restaurant, hiring one cook who can handle N orders
at the same time is more efficient than hiring N cooks who can only handle
one order apiece.

For N-way multitasking, ideally the latency scales like N^0 and ideally the
throughput scales like N^1, but in practice the exponents are somewhat
greater than 0 and less than 1 (respectively).

The article says:
> So the brain starts switching. Scan for red. Switch. Scan for blue. Switch. Scan for green. Switch.

Scanning is exactly the verb pilots use to describe that part of the process.
Scanning for traffic.  Scanning the instruments.

I would hasten to a that "scanning" describes only part of the process.
You have to scan the inputs and _interpret_ what you see so as to build a
mental model of what's going on.  The mental model is primary and fundamental.
One of the functions of the mental model is to tell you what needs scanning
right now and what doesn't.

As a flight instructor, I teach scanning ... and modeling.  I constantly and 
explicitly check the student's scan.  Partly I watch the student's eyes, so 
I can know what he's looking at.  Also if I notice something, I measure how 
long it takes for the student to notice.  Even if nothing is changing, I can 
check whether the student /knows/ nothing is changing.  For example, I might
cover up the altimeter and vertical speed indicator, and ask "what is our 
vertical speed and altitude".  To a first approximation I don't care if we 
are 100 feet high or low, so long as the student /knows/ what the situation 
is, because that means he will very soon learn to make the problem go away.
Conversely, if the student says "I have no idea" it means his mental model 
is missing some critical pieces.  Loosely speaking people call this a "scan
breakdown" but more precisely it is a model breakdown.  A good scan is necessary
but not sufficient for having a good mental model.

The mental model endures, even if some of the inputs are temporarily cut off.
As a familiar example, when you are driving, I hope you have a mental model of 
what nearby traffic is doing.  If you see a car pull into your blind spot and
don't see it leave, I hope your mental model tells you that you have a car in
your blind spot, even though you can't see it.  You need not and *should not*
fixate on that car.

There are lots of things I can do to teach and evaluate the mental model.  For
example, I might assign the following challenges:
 -- Without looking, tell me where the nearest traffic is. 
 -- Without looking, point to the airport, or just tell me where it is relative
  to our current position.
 -- I have covered up the altimeter, but I want you to to maintain such-and-such
  altitude.  This is annoying but perfectly doable if you have a good mental model.
  To a first approximation, if you do a good job of preventing pitch excursions
  and airspeed excursions, there won't be any altitude excursions, especially
  in calm weather conditions.  To a better approximation, especially when there 
  are nasty updrafts and downdrafts, you can mentally compute the time-integral 
  of the vertical speed indicator.  Every five minutes you and I will have a contest 
  to see whose mental model is better.  We each predict what the altimeter will 
  say, and then we peek.  Then we cover it up and the game continues.

The point is explicit.  There is nothing subtle about it.  The point is that the 
mental model is primary and fundamental.  You scan as needed to keep the mental 
model up-to-date.  Things that change quickly need to be scanned more often than 
things that don't.  For example, pitch attitude can change quickly, so give that 
a lot of priority.  If you fix the pitch excursion *before* it becomes an altitude 
excursion, it suffices to scan the altimeter very infrequently.

Yet another way to see that "scanning" is an incomplete description is the curious 
incident of the dog in the night-time.
  http://en.wikipedia.org/wiki/Silver_Blaze
That is, whereas a barking dog demands your attention, sometimes the most significant 
input is something that did not leap up and demand your attention, something that you
did not see or hear during your scan, something that must be inferred indirectly by
checking for inconsistencies in the mental model.

===================

Hunting and cooking and flying are by no means the only examples.  Management is
another.  As a first-level lab manager, you might have 10 or 20 people reporting
to you.  If you're lucky, they're all working on the same project ... but quite
possibly they are doing N different things.  In the course of a single day, you 
might have N of them show up at your office, each asking for help with their
own project.  This requires context switching.  They expect you to resume the
conversation about their particular project right where you left off the day
before.  To say the same thing the other way, if you had to start from scratch 
each day ("Tell me again who you are and what you are working on ...."), that 
would be a failure of multitasking.

As a second-level (or higher) manager, the demands are even greater.  The general 
rule is that each person should be able to see two levels up the tree and two 
levels down the tree.  So if the span is S = 10 at each level, that means there 
are on the order of S^2 + S = 110 people you need to keep track of.

You can call this whatever you like.  I call it multitasking.