This tutorial shows how to use Performance Analyzer on a multithreaded program to examine clock profiling and synchronization tracing data.
You use the Overview page to quickly see which performance metrics are highlighted and change which metrics are shown in data views. You use the Functions view, Callers-Callees view, and the Source view to explore the data. The tutorial also shows you how to compare two experiments.
The tutorial helps you understand synchronization tracing data, and explains how to relate it to clock-profiling data.
The data you see in the experiment that you record will be different from that shown here. The experiment used for the screen shots in the tutorial was recorded on a SPARC T5 system running Oracle Solaris 11.3. The data from an x86 system running Oracle Solaris or Linux will be different. Furthermore, data collection is statistical in nature and varies from experiment to experiment, even when run on the same system and OS.
The Performance Analyzer window configuration that you see might not precisely match the screen shots. Performance Analyzer enables you to drag separator bars between components of the window, collapse components, and resize the window. Performance Analyzer records its configuration and uses the same configuration the next time it runs. Many configuration changes were made in the course of capturing the screen shots shown in the tutorial.
The program mttest is a simple program that exercises various synchronization options on dummy data. The program implements a number of different tasks and each task uses the same basic algorithm:
Queue up a number of work blocks (4, by default).
Spawn a number of threads to process them (also, 4, by default).
In each task, use a particular synchronization primitive to control access to the work blocks.
Process the work for the block, after the synchronization.
Each task uses a different synchronization method. The mttest code executes each task in sequence.
Synchronization tracing is implemented by interposing on the various library functions for synchronization, such as mutex_lock(), pthread_mutex_lock(), sem_wait(), and so on. Both the pthread and Oracle Solaris synchronization calls are traced.
When the target program calls one of these functions, the call is intercepted by the data collector. The current time, the address of the lock, and some other data is captured, and then the interposition routine calls the real library routine. When the real library routine returns, the data collector reads the time again and computes the difference between the end-time and the start-time. If that difference exceeds a user-specified threshold, the event is recorded. If the time does not exceed the threshold, the event is not recorded. In either case, the return value from the real library routine is returned to the caller.
You can set the threshold used to determine whether to record the event by using the collect command's -s option. If you use Performance Analyzer to collect the experiment, you can specify the threshold as the Minimum Delay for Synchronization Wait Tracing in the Profile Application dialog. You can set the threshold to a number of microseconds or to the keyword calibrate or on. When you use calibrate or on the data collector determines the time it takes to acquire an uncontended mutex lock and sets the threshold to five times that value. A specified threshold of 0 or all causes all events to be recorded.
In this tutorial, you record synchronization wait tracing in two experiments, with one experiment having a calibrated threshold and one experiment with a zero threshold. Both experiments also include clock profiling.