We all know that trying to design and understand the behavior of programs that contain concurrency/parallelism is more difficult than understanding single-threaded programs.By their nature, they can become quite complicated and large. Threads are assigned to cores then those threads can create even more threads that communicate by passing messages, sending signals, periodically synchronizing, competing for resources, then producing vast amounts of data.

The execution of these threads require coordination by using synchronization relationships, scheduling policies, PRAM, delegation models, etc. Execution of threads may cause unforeseen interactions or even irreproducibility of output due to non-determinism meaning multiple executions of the same program has inconsistent results. Both makes the program difficult to debug.

With single-threaded programs, a breakpoint is set and the program's execution will be momentarily suspended. Then a snapshot of the state of the program can be examined. With a program containing multiple threads, several threads will have to be suspended and messages between those threads have to be considered in order to determine the global state of the program. Examining messages in transit and analyzing the output to see if it is correct becomes even more difficult. Even with many parallel debuggers, presentation can be highly textual with disjoint snapshots of subsets of the program state allowing the most interesting events to be overlooked. There is also synchronization errors, deadlock, and performance optimization to be considered.

But all of this should not be an afterthought. Synchronization relationships, work delegation, resource allocation, and read/write access to shared memory should be considered during the design phase of systems containing parallelism. Although threads should have a certain amount of independence, message passing and synchronization can be constantly occurring. For example, take a 3D scene that contains many 3D models that are to be animated. From a thread pool, a separate animation thread is assigned to model. A 3D bat model is animated to hit a 3D ball, each having its own animation thread. The ball cannot be animated until the bat model actually comes in contact (collision detection) with the 3D ball. Thread A cannot read the data from a database until Thread B performs the calculation and writes the new data to the database. These types of actions are all performed while many other threads are fulfilling their responsibilities simultaneously. This can be a daunting task to the designer and developer of a system but there are many tools and techniques she/he can utilize to make it all work as expected.

Graphical visualization can be used throughout the software development phases. It can be a powerful tool to help the developer understand some of the complicated tasks in parallel computations. Visualization is the transforming of information into a meaningful visual representation in order to gain understanding. UML (United Markup Language) has a plethora of diagramming techniques that can be used from the design phase to deployment. Figure 1 shows UML sequence diagrams used to show synchronization relationships between threads.

Tools such as ParaGraph is a graphical display tool for visualizing the performance and the behavior of parallel programs that utilizes MPI (Message-Passing Interface). The animation or "visual playback" ParaGraph creates of the system is based on an execution trace of information gathered while the program is executing. The animation graphically represents the behavior and performance of the system overall. ParaGraph provides multiple types of displays or views (at least 30) in the areas of utilization, communication, and task displays. XPVM also visualizes the execution of a program. It provides several views including network and space-time views, and a task utilization vs. time view.

UML, ParaGraph, and XPVM are pretty standard tools. In upcoming blogs, we will discuss these and some other visualization diagrams, tools and techniques, some old and some new.