Locks and Resource Usage

The Execution Profiler cannot directly determine when a thread uses a logical or physical resource. Instead, the profiler records when a thread waits for, acquires, or releases a TestStand lock. Typical TestStand applications use TestStand locks to surround the use of logical and physical resources to guarantee that only one thread accesses the resources at a time. Because lock acquisition and resource usage correspond, viewing the time line of lock acquisitions provides a close approximation of actual resource usage. In addition, because threads wait to acquire locks rather than resources, viewing lock operations shows when threads block waiting for a resource to become available. If threads block excessively because of limited resources or a design flaw, viewing the associated lock operations can highlight the location of the performance issue.

A system might use resources you protect with mechanisms other than TestStand locks, including lower-level primitives, such as operating system critical sections and mutexes. To view the uses of resources with non-TestStand locks in the profiler, you must also surround the resources with TestStand locks.

Depending on the system, you might be able to place TestStand locks at a much higher level than the underlying thread synchronization. For example, if a step calls a code module you write that spends most of its time in a call to an instrument driver function that internally synchronizes thread access to the instrument, you can place a TestStand lock around the calling step to approximate the instrument driver synchronization in a way that is viewable in the profiler.

Use the Lock step type or the Use Lock to Allow Only One Thread at a Time to Execute the Step option to create and invoke TestStand locks. You can also call the TestStand API to create and invoke TestStand locks from within code modules you write.