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.