|
BDE 4.14.0 Production release
|
Provide a mechanism to collect process performance measures.
This component provides an application developer the means to collect and report performance statistics for an arbitrary number of processes running on the local machine. The balb::PerformanceMonitor provides the mechanism for doing so, the balb::PerformanceMonitor::Statistics class holds the data and the balb::PerformanceMonitor::ConstIterator class is used to iterate over the data. The following table describes the measures collecting by this component. Note that all the collected measures are specific to the monitored process and do not refer to any system-wide measurement.
Various OSs might require specific permissions in order to inspect processes other than the current process. For example, on Darwin, users other than root can only inspect processes running under the user with which the current process is running. This error condition will be indicated by a non-zero return value from registerPid.
Note that this component is not supported when building in 32-bit mode with the g++ compiler on Solaris, due to Solaris's procfs.h header not supporting that compiler in 32-bit mode. (DRQS 170291732)
Registration of new pids does not invalidate existing iterators. Unregistration of a pid invalidates only iterators pointing to the statistics for the pid being unregistered. Additionally, unregistering a pid with a balb::PerformanceMonitor object invalidates all references to Statistics objects retrieved from those iterators. All other iterators remain valid.
The classes balb::PerformanceMonitor and balb::PerformanceMonitor::Statistics, provided by this component, are both independently fully thread-safe (see bsldoc_glossary ). However, balb::PerformanceMonitor::ConstIterator is only const thread-safe, meaning it is not safe to access or modify a ConstIterator in one thread while another thread modifies the same object. As unregistering a pid with a balb::PerformanceMonitor object invalidates iterators (see {Iterator Invalidation}), external synchronization is needed if unregisterPid is called concurrently to iterating over statistics. Also, in a multi-threaded context, a Statistics object accessed via a reference (or pointer) from a ConstIterator object may have its statistics updated at any time by a call to collect or resetStatistics in another thread. If consistent access is needed to multiple items in a set of statistics, then the user should copy the statistics object, and then inspect the copy at their leisure.
Notice that this component was implemented with particular usage patterns in mind, which are captured in the usage examples.
This section illustrates intended use of this component.
The following example shows how to monitor the currently executing process and produce a formatted report of the collected measures after a certain interval.
First, we instantiate a scheduler used by the performance monitor to schedule collection events.
Then, we create the performance monitor, monitoring the current process and auto-collecting statistics every second.
Next, we print a formatted report of the performance statistics collected for each pid every 5 seconds for half a minute. Note, that Statistics object can be simultaneously modified by scheduler callback and accessed via a ConstIterator. To ensure that the call to Statistics::print outputs consistent data from a single update of the statistics for this process, we create a local copy (copy construction is guaranteed to be thread-safe).
Finally, we unregister the process and stop the scheduler to cease collecting statistics for this process. It is safe to call unregisterPid here, because we don't have any ConstIterators objects or references to Statistics objects.