Analyzing diagnostic data generated by multiple threads within an instruction stream

Abstract

A diagnostic method for outputting diagnostic data relating to processing of instruction streams stemming from a computer program, at least some of said instructions streams comprising multiple threads is disclosed. The method comprises the steps of: (i) receiving diagnostic data; (ii) reordering said received diagnostic data in dependence upon reordering data, said reordering data comprising data relating to said computer program; and (iii) outputting said reordered diagnostic data. In general, the instructions streams are processed by a plurality of processing units arranged to process at least some of said instructions in parallel, said diagnostic data being received from said plurality of processing units.

Description

BACKGROUND OF THE INVENTION[0001]1. Field of the Invention[0002]The present invention relates to the field of data processing and in particular to diagnostic mechanisms for monitoring data processing operations.[0003]2. Description of the Prior Art[0004]Systems are being developed that have multiple processing units operable to process data in parallel. A compiler will compile a program to execute on a particular hardware system such that in a multi-processor system portions of the program will be sent to be executed by different processing units. Thus, much of the program will be executed in parallel and executing times and processing performance will be improved. However, a drawback of this is that the view of the program execution derived from diagnostic mechanisms such as debug are difficult for a programmer to understand and to relate back to the original sequential program.[0005]When an application has been split into multiple threads automatically, there are two conventional ...

AI Technical Summary

Benefits of technology

[0018]In order to address the problem of a computer program that is divided into a plurality of threads, being hard to analyse when it is being processed, the present invention analyses any diagnostic data generated in conjunction with data relating to the original written computer program. It uses the information from the original written computer program as reordering data to help in reordering the received diagnostic data and it is this reordered diagnostic data that is then analysed. Thus, the diagnostic data received can be reordered into a form that more closely matches the original computer program and thus is easier for a programmer to understand and analyse. It should be noted that a computer program may be divided in to a plurality of threads prior to execution when it is to be executed on multiple processing or execution units in parallel, or it may be so divided by a compiler in the expectation that the program will run on such a platform, although the execution is actually performed by a single processor.

[0065]As previously mentioned, when compiling a computer program to be processed by a plurality of processing units decisions on how the program is divided and which bits are sent to which processor are made. Thus, if additional information regarding this process can be output by the compiler this could considerably help the reordering of any diagnostic data that may occur later. Thus, it is advantageous if compilers can generate and output information that will give hints on how the parallelisation of the program was performed.

Problems solved by technology

However, a drawback of this is that the view of the program execution derived from diagnostic mechanisms such as debug are difficult for a programmer to understand and to relate back to the original sequential program.

Clearly this has the disadvantage of not allowing diagnosis of a significant part of the program.

In summary, when multiple processors are executing in parallel and independently producing traces of diagnostic information, it can be hard to understand the resulting traces independently of each other.

While this approach does significantly simplify the event stream, it leaves a significant semantic gap between the program as written by the programmer and the program as executed on the multi-processor system.

This makes debugging the system harder because the programmer must disregard the order of some events (e.g., exactly when does T3 run) while paying careful attention to other events (e.g., that T1 and T2 execute in sequence).

The problem identified above comes from the topological sort making sorting decisions based only on how the hardware runs the output of the transforming compiler.

Furthermore, diagnosis can be difficult when an application has been written as a number of separate threads or even as a number of separate programs or where it is not possible to modify the part of the compiler that automatically parallelizes the program.

Having a single trace is, in some sense simple but the trace is hard to understand because of the interleaving of multiple independent operations which requires the programmer to keep many things in their head at once.

This is complicated as it requires the programmer to reason carefully about the communication protocol used between the different threads.

This can help program understanding but not debugging because it can only display a subset of the trace (those sequences whose probability of being causally related is high) and because even though a sequence is probably correct, it may still be wrong so there is a possibility of confusion.

Furthermore, because of its statistical nature, long sequences of operations are hard to construct because it takes a lot of observations before one can be confident that a sequence of 100 fairly probable events is itself fairly probable.

Images