time needed for a task.
˲ Some tasks need to be held aside
in an inactive status until you have the
capacity to deal with them. Analog: the
waiting tasks queue.
˲ When a task’s working set is in
your workspace, protect it from being
unloaded as long as the task is active.
Analog: protect working sets of active
tasks and do not steal from other tasks.
˲ You will thrash if you activate too
many tasks so that the total demand is
beyond your capacity. Analog: insufficient CPU and memory for active tasks.
˲ If you are able to choose moments
of context switch, select a moment of
“clean break” that requires little mental reacquisition time when you return
to the task. If you cannot defer an interruption to such a moment, you will
need more reacquisition time because
you will have to reconstruct short-term
memory lost at the interruption. Analog: ill-timed interrupts can cause loss
of part of a working set.
You are likely to find that you cannot accommodate more than a few
active tasks at once without thrashing. However, with the precautions
described here, thrashing is unlikely.
If it does occur you will feel overwhelmed and your processing efficiency will be badly impaired. To exit
the thrashing state, you need to reduce
demand or increase your capacity. You
can do this by reaching out to other
people—making requests for help, renegotiating deadlines, acquiring more
resources, and in some cases canceling less important tasks.
1. Allen, D. Getting Things Done. Penguin. 2001.
2. Christian, B. and Griffiths. T. Algorithms to Live By: The
Computer Science of Human Decisions. Henry Holt
and Company, 2016.
3. Denning, P. Working sets past and present. IEEE Trans
Software Engineering SE- 6, 1 (Jan. 1980), 64–84.
4. Denning, P. and Martell, C. Great Principles of
Computing. MI T Press, 2015.
5. Flores, F. Conversations for Action and Collected
Essays. CreateSpace Independent Publishing
6. McMenamin, A. Applying working set heuristics to
the Linux kernel. Masters Thesis, Birkbeck College,
University of London, 2011; http://bit.ly/2vFSg Y8
7. Napier, N. The myth of multitasking, 2014; http://bit.
Peter J. Denning ( email@example.com) is Distinguished
Professor of Computer Science and Director of the
Cebrowski Institute for information innovation at
the Naval Postgraduate School in Monterey, CA,
is Editor of ACM Ubiquity, and is a past president of ACM.
The author’s views expressed here are not necessarily
those of his employer or the U.S. federal government.
Copyright held by author.
sive focused practice with it. Some fret
that if we do not learn to manage our
multitasking well, we may wind up becoming a world of dilettantes with few
experts to keep our technology running.
Thrashing happens to human multitaskers when they have too many incomplete tasks. They fall into a mood
of “overwhelm” in which they experience considerable stress, cannot
choose a next task to work on, and cannot stay focused on the chosen task. It
can be a difficult state to recover from.
Let us now take a look at what OSs
do to avoid thrashing and see what lessons we can take to avoid it ourselves.
Locality, Working Sets, and Thrashing
The OS seeks to allocate memory
among multiple tasks so as to maximize system throughput—the number
of completed tasks per second. 3
The accompanying Figure 1 is strong
graphical evidence of the principle of locality—computations concentrate their
memory accesses to relatively small locality sets over extended intervals. Locality should be no surprise—it reflects the
way human designers approach tasks.
We use the term working set for OS’s
estimate of a task’s locality set. The formal definition is that working set is
the pages used in a backward-looking
window of a fixed size T memory references. In Figure 1, T is the length of the
sampling interval and the working set
equals the locality set 97% of the time.
Each task needs a workspace—its
own area of memory in which to load its
pages. There are at least two ways to di-
vide the total memory among the active
tasks. In fixed partitioning, the OS gives
each task a fixed workspace. In work-
ing-set partitioning, the OS gives each
task a variable workspace that tracks
its locality sets. Fixed partitioning is
susceptible to thrashing as the num-
ber of tasks sharing memory increases
because each gets a smaller workspace
and, when the workspaces are smaller
than the working sets, every task is
quickly interrupted by a page fault.
Under working-set partitioning
the OS sizes the workspaces to hold
each task’s measured working set. As
shown in Figure 2, it loads tasks into
memory until the unused free space is
too small to hold the next task’s working set; the remaining tasks are held
aside in a queue until there is room for
their working sets. When a task has a
page fault, the new page is added to its
workspace by taking a free page; when
any page has not been used for T memory references, it is evicted from the
task’s workspace and placed in the free
space. Thus, the OS divides the memory
among the active tasks such that each
task’s workspace tracks its locality sets.
Page faults do not steal pages from other working sets. This strategy automatically adjusts the load (number of active
tasks) to keep throughput near its maximum and to avoid thrashing.
Context switching is not the cause of
thrashing. The cause of thrashing is the
failure to give every active task enough
space for its working set, thereby causing excessive movement of pages between secondary and main memory.
Translation to Human Multitasking
Although the analogy with OSs is not
perfect, there are some lessons:
˲ Recognize that each task needs a
variable working set of resources (
physical, digital, and mental), which must
be easily accessible in your workspace.
Analog: the working set of pages.
˲ Your capacity to deal with a task is
the resources and time needed to get
it done. Analog: the memory and CPU
Figure 2. OS control system to maximize throughput with variable partition of main
memory determined by task working sets.
main memory (active tasks)
open valve when
first waiting task’s
WS fits into free
aside by OS
WS1 WS1 WS3 WS4