A Couple of Processes

When programmers write single-threaded, single-process programs, they can almost always answer the question "Do you know where your program is?" These kind of programs are rather simple, looking something like this:

A Uniprocessor

If you use a debugger, any debugger, on something like this, you can almost always figure out what is going on. Before the program begins executing, you set a breakpoint, let the program run until it hits the breakpoint, and then inspect variables to see what they have been set to. If you suspect there is a logic problem, you can step the program through its statements, seeing what happens and where things are going wrong.

What is actually occurring is a lot more complicated than this as your computer is executing a great number of programs. For example, your computing environment could have daemons and other support programs executing.

A Program and Daemons

These additional processes simplify a programmer's life because the application program no longer had to do everything itself. It could hand some things off to another program or process and it would do the program's bidding.

The preceding figure assumes that the application program only sends requests to the daemon. More complicated architectures are quite common. For example, the following figure shows an E-mail program communicating with a daemon on its computer. After receiving a request, this daemon sends data to an E-mail daemon on another computer which then delivers the data.

Mail with Daemons

This kind of processing assumes that the jobs are disconnected. That is, no real cooperation exists between the processes. In all cases, one program hands work to another. After the handoff occurs, there is no more interaction. While this is an extremely useful model, a more general model is one where a program divides its work, parceling it out to other computers. When this occurs, one program relies on another program to do some of its work. To gain any advantage, however, the work being sent to the second computer has to be work that the first computer does not need right away. In this way, the two computers act more or less independently. And, because the first computer did not have to do the work that the second computer did, the program could complete faster.

Two Computers Working on One Problem

Here is one of the problems with this scenario: because programs have bugs, how does a programmer debug what is happening on the second computer? A horrid solution is to have a debugger running on each computer. A slightly better solution is to create a program the same way as was done with one computer, get it working, and then split it up so it could use more than one computer. If done this way, there is a likelihood that any problems that occur will occur in the code that splits up the problem.

The TotalView solution is even better. It places a server on each processor as a program is launched. The server then communicates with the "main" TotalView. This debugging architecture gives you one central location from which you can manage and examine all aspects of your program.