Using the Concert Emulator

In the last section, you were introduced to the Concert Emulator; here we will explored it a little more deeply. Three major features of the emulator will be described: interactive modification of code, different scheduling policies and tracing facilities. Lets use a familiar example to illustrate some features of the emulator. Load the hello world program into Emacs, and once more run the emulator and load the program.

Interactively Modifying Programs

The emulator allows you to redefine parts of the program by typing them in at the concert> prompt. Redefine the hello world program by typing the following text in at the emulator prompt.

(method osystem initial_message ()
  (HELLO_WORLD (global console))
  (HELLO_AGAIN_WORLD (global console))
  (reply DONE))

Now try running the program. The result should be the same as last time, except for a new message, HELLO_AGAIN_WORLD, appearing on the screen. This procedure would look like the session in Figure 5

Concurrency and Scheduling

Multiple message sends in a method are by default concurrent, so the three message sends in the above method could potentially execute in any order. This is the basic mechanism for specifying concurrency in Concert programs. Since a major cause of bugs in all kinds of parallel programs is incorrect concurrency, the emulator provides a scheduler that executes concurrent pieces of code in different orders under user control. There are four different scheduling policies that can be selected: stack, fifo, random-repeating and random. The command for setting the scheduling policy is (set scheduler ...); try out each of the policies and compare the order of the three messages on the screen. The stack policy might produce output like Figure 6; note the different order of the messages in this figure and Figure 5.

When writing Concert programs of any size, it is always a good idea to run it under different scheduling policies. This is a good way to find concurrency errors; if the program contains a mistake, it is very unlikely to work correctly under all four scheduling policies, while, if you only use one, it may hide some types of errors.

Tracing Execution

The Concert Emulator also provides functionality for tracing execution of Concert programs; in this context, tracing means notification when methods are called and executed. A method is called when the message send is executed, and are executed when the actual method code starts execution. In a Concert program, due to concurrency control, these may not be the same.

To trace when methods are called, use the (trace_dispatchclassname selector) command, which will print a message when the method selector is invoked on an object of class. To trace when methods are actually executed, use the (trace_receiveclassname selector) command, with the same arguments as before. To trace both calling and execution of a method, use the (trace classname selector) command. These commands produce messages describing what is happening while the program executes; for example, tracing the initial_message, the only method of the hello world program, would produce the results like those of Figure 7.

All of the trace commands have an analogous untrace command that takes the same arguments and turns off tracing for that method and class. There are also trace-all and untrace-all commands that turn tracing on and off for the entire program.

This is only a sample of the Concert Emulator functionality; for a complete description of all available commands, see [6].