Age group Middle elementary and up.
Abilities assumed Working in a group to solve a problem.
Time 20 minutes or more.
Size of group About five children or more, can be adapted for a single person.
Focus
Cooperative problem solving.
Logical reasoning.
Planning.
Summary
When people are contending for scarce resources, careful planning is needed. When there are dependencies amongst the demands for a resource (such as cars using roads, or messages getting through networks) there is the possibility of “deadlock,” where a stalemate is reached and someone must back off before anyone can proceed. This activity gives children experience with a situation where they are contending for resources. A cooperative procedure is required for everyone to accomplish the desired result without becoming deadlocked.
Figure 10.1: Playing the game with six children and eleven oranges; child D has an empty hand
Technical terms
Routing; deadlock; message passing.
Materials
Each child will need:
two oranges (or some other tokens that can be labeled), and a name tag or sticker.
What to do
1. Form the children into groups of about five or more, and seat each group in a circle. (It can be helpful to start with just one group and have everyone else watch first. The game can take as long as 15 minutes, but there is no need to watch it to completion.)
2. The members of the group are given two oranges each (or balls, or cards), except for one child who has only one. The children are labeled with a letter of the alphabet, and their oranges are labeled with the same letters, two oranges per letter. The children wear name tags or stickers showing their letter. The oranges are mixed up so that people don’t have any with their own letter on. The children hold one orange in each hand. Figure 10.1 shows a possible arrangement of children and oranges.
3. The object of the game is for the children to pass the oranges around so that each child ends up holding their corresponding oranges—that is, child A is holding both oranges labeled A, and so on. They must follow two rules:
(a) Only one orange may be held in a hand.
(b) An orange can only be passed to an empty hand of an immediate neighbor in the circle.
The rules mean that for the arrangement in Figure 10.1, the only allowed move is for child C or child E to hand child D an orange. In the case of C this could be either the B or E orange.
Children will quickly find that if they are “greedy” (hold onto their own oranges as soon as they get them) then the group might not be able to attain its goal. It may be necessary to emphasize that individuals don’t “win” the game, but that the puzzle is solved when everyone has their oranges.
If the children are having difficulty making progress, it may be helpful to suggest that they imagine a wall between child A and F, which is equivalent to the children being in a line rather than a circle. (One strategy that works is to sort the letters into alphabetical order simply by swapping letters that are out of order.)
4. If a group finishes early they could try one of the variations suggested below.
5. Afterwards, have the children discuss the strategies that they used to solve the problem.
Variations and extensions
Many variations of this game are possible. Some possibilities are:
1. Try the activity with a larger or smaller circle.
2. Have the children come up with variant rules.
3. Carry out the activity without any talking.
4. Try a different configuration for message passing, such as sitting in a line, or having more than two neighbors for some children (see Figure 10.2).
5. This problem can be simulated by a single person manipulating the tokens; cooperation is now automatic, but strategies can still be explored.
Discuss where children have experienced the problem of deadlock. Some examples might be a traffic jam or gridlock in a road network, getting players around bases in baseball, or trying to get a lot of people through a doorway at once.
(a) (b)
(c)
Figure 10.2: Some configurations for the orange game: (a) circle, (b) line, (c) grid. The lines show where oranges can be passed.
What’s it all about?
Routing and deadlock are important problems in many different kinds of networks, such as road systems and traffic jams, telephone and computer systems. Engineers spend a lot of time figuring out how to solve these problems—and how to design networks for which the problems are easier to solve.
Routing, congestion and deadlock can present frustrating problems in many different kinds of networks. Just think of your favorite rush-hour traffic! It has happened several times in New York City that the traffic in the streets has become so congested that it deadlocks: no-one can move their car! Many times when the computers are “down” in businesses (such as banks) the problem is caused by a communication network deadlock. Designing networks so that routing is easy and efficient and congestion is minimized is a difficult problem faced by many kinds of engineers.
A classic (though somewhat dated) example of deadlock in computing is when two people on a shared computer are running a program that uses both a tape reader and a printer. Person A issues a command to read some data from a computer tape, and print it out. To do this, the computer must allocate the tape reader and the printer to person A. Suppose the tape reader gets allocated to person A, but before the printer is allocated, person B’s program makes a request for the same resources, and is allocated the printer first. The two programs are now deadlocked:
neither can proceed until the other releases a resource.
A more likely scenario on modern computers is when users are competing for data in a database. If a piece of data (such as a customer’s bank balance) is being updated, it is important to “lock” it during the update because otherwise a simultaneous update from another source could result in the balance being recorded incorrectly. Deadlock could occur when two people
are accessing the same data in a different order. Such a situation must be prevented because when it occurs the people involved will have to wait indefinitely for a response. While it may not seem to be very likely to happen, it is a fact that if it is possible for a system to deadlock, it certainly will. This sounds like Murphy’s law—that if things can go wrong they will—but it is a lot stronger than Murphy’s law because it doesn’t just happen by bad luck: you can prove that if a system that is subject to random inputs can deadlock, it surely will eventually. And things become even more complicated if multiple requests are involved in the deadlock situation.
One of the most exciting developments in computer design is the advent of parallel comput-ing, where hundreds or thousands of PC-like processors are combined (in a network, of course) to form a single powerful computer. Many problems like the Orange Game must be played on these networks continuously (but much faster!) in order for these parallel computers to work.
Further reading
Many books about computer operating systems, such as Tanenbaum’s book Operating Systems, have a section on deadlock. Tanenbaum’s book includes the Ostrich Algorithm (ignore the problem) and the Banker’s algorithm (analagous to a banker with a limited amount of money to lend in a community). This kind of problem is also discussed in Peterson’s book Petri Net Theory and the Modeling of Systems.