Anonymous avatar Anonymous committed 3d01e3c

adding doxygen + Modifed IPerfMonSvc interface so it becomes clear what this service does (thx to the documentation ;)

Comments (0)

Files changed (5)

+2007-06-12  Sebastien Binet  <binet@lblbox>
+
+	* tagging PerfMonKernel-00-02-00
+	* adding doxy-comments for documentation standdown
+	* Modifed IPerfMonSvc interface so it becomes clear what this service
+	  does (thx to the documentation ;)
+
 2007-06-07  Sebastien Binet  <binet@lblbox>
 
 	* tagging PerfMonKernel-00-01-04

PerfMonKernel/IPerfMonPyTool.h

 #ifndef PERFMONKERNEL_IPERFMONPYTOOL_H 
 #define PERFMONKERNEL_IPERFMONPYTOOL_H 
 
+/** @class IPerfMonPyTool
+ *  The interface to tools meant to monitor the python Configuration step.
+ *  Hence, only one monitoring method has been declared:
+ *   - @c IPerfMonPyTool::pyMonitor
+ *
+ *  Monitoring is supposed to take place before the creation of a concrete tool 
+ *  implementing this @c IPerfMonPyTool interface, by some python class or 
+ *  other means. The performance data is then transmitted to the tool by some
+ *  jobOption property.
+ *  The assumption that performance data is in good shape and may be committed 
+ *  to persistent storage is nonetheless enforced by the same mechanism (ie: 
+ *  @c IPerfMonPyTool::shutdown)
+ */
+
 // STL includes
 
 // FrameWork includes

PerfMonKernel/IPerfMonSvc.h

 #ifndef PERFMONKERNEL_IPERFMONSVC_H 
 #define PERFMONKERNEL_IPERFMONSVC_H 
 
+/** @class IPerfMonSvc
+ *  This is the interface to the main service scheduling a performance 
+ *  monitoring job.
+ *  Not much is exposed to clients as it is supposed to be a rather opaque black
+ *  box, but the following methods are heavily suggested to be implemented by 
+ *  derived classes:
+ *    - IPerfMonSvc::pyMonitor
+ *    - IPerfMonSvc::monitorInitialize
+ *    - IPerfMonSvc::monitor
+ *    - IPerfMonSvc::monitorFinalize
+ *
+ *  However, to minimize coupling between (concrete) classes, 2 methods are
+ *  implemented here: @c shutdown( IPerfMonPyTool* ) and 
+ *  @c shutdown( IPerfMonTool* ).
+ *  These methods are the last chance provided to these tools to gather metadata
+ *  and clean-up the state of their performance data. After that, nothing else
+ *  will be committed to disk (ie: to the tuple) or at least no change will be
+ *  reflected on the persistent side.
+ *  Note that these methods have been introduced because the meaning of
+ *  finalizing a tool (in the Gaudi sense) can differ from finalizing a
+ *  performance monitoring task. So they had to be decoupled.
+ */
+
 // STL includes
 
 // FrameWork includes
   /////////////////////////////////////////////////////////////////// 
  protected: 
 
+  /// main entry point for the performance monitoring (of python)
+  virtual void pyMonitor() = 0;
+
+  /// main entry point for the performance monitoring (of initialize)
+  virtual void monitorInitialize() = 0;
+
+  /// main entry point for the performance monitoring
+  virtual void monitor() = 0;
+
+  /// main entry point for the performance monitoring (of finalize)
+  virtual void monitorFinalize() = 0;
+
   /// shutdown an @c IPerfMonTool
   StatusCode shutdown( IPerfMonTool* tool );
 

PerfMonKernel/IPerfMonTool.h

 #ifndef PERFMONKERNEL_IPERFMONTOOL_H 
 #define PERFMONKERNEL_IPERFMONTOOL_H 
 
+/** @class IPerfMonTool
+ *  the interface to tools meant to monitor the various stages of the Gaudi 
+ *  finite state machine (@c IAlgorithm::initialize @c IAlgorithm::execute 
+ *  @c IAlgorithm::finalize ...). 
+ *
+ *  Hence, the following hopefully self-explanatory methods are declared:
+ *   - @c IPerfMonTool::monitorInitialize
+ *   - @c IPerfMonTool::monitor
+ *   - @c IPerfMonTool::monitorFinalize
+ *
+ *  Monitoring is supposed to take place upon creation of a concrete tool 
+ *  implementing this @c IPerfMonTool interface, until the call to the 
+ *  @c IPerfMonTool::shutdown method.
+ */
+
 // STL includes
 
 // FrameWork includes
+/**
+@mainpage PerfMonKernel Package
+@author Sebastien Binet
+
+@section PerfMonKernelIntro Introduction
+
+This package provides the abstract interfaces to the (Gaudi) components (tools and services) needed and used by the performance monitoring packages.
+
+@section PerfMonKernelOverview Class Overview
+  The PerfMonKernel package contains the following classes:
+
+  - IPerfMonSvc : the main service organizing and scheduling a performance monitoring job. Not much is exposed to clients as it is supposed to be a rather opaque black box, but the following methods are heavily suggested to be implemented by derived classes:
+     - IPerfMonSvc::pyMonitor
+     - IPerfMonSvc::monitorInitialize
+     - IPerfMonSvc::monitor
+     - IPerfMonSvc::monitorFinalize
+
+However, to minimize coupling between (concrete) classes, 2 methods are implemented here: @c IPerfMonSvc::shutdown( IPerfMonPyTool* ) and @c IPerfMonSvc::shutdown( IPerfMonTool* ). These methods are the last chance provided to these tools to gather metadata and clean-up the state of their performance data. After that, nothing else will be committed to disk (ie: to the tuple) or at least no change will be reflected on the persistent side. 
+Note that these methods have been introduced because the meaning of finalizing a tool (in the Gaudi sense) can differ from finalizing a performance monitoring task. So they had to be decoupled.
+
+  - IPerfMonTool : the interface to tools meant to monitor the various stages of the Gaudi finite state machine (@c IAlgorithm::initialize @c IAlgorithm::execute @c IAlgorithm::finalize ...). Hence, the following hopefully self-explanatory methods are declared:
+     - @c IPerfMonTool::monitorInitialize
+     - @c IPerfMonTool::monitor
+     - @c IPerfMonTool::monitorFinalize
+
+Monitoring is supposed to take place upon creation of a concrete tool implementing this @c IPerfMonTool interface, until the call to the @c IPerfMonTool::shutdown method.
+
+ - IPerfMonPyTool : the interface to tools meant to monitor the python Configuration step, hence only one monitoring method has been declared:
+     - @c IPerfMonPyTool::pyMonitor
+
+Monitoring is supposed to take place before the creation of a concrete tool implementing this @c IPerfMonPyTool interface, by some python class or other means. The performance data is then transmitted to the tool by some jobOption property.
+The assumption that performance data is in good shape and may be committed to persistent storage is nonetheless enforced by the same mechanism (ie: @c IPerfMonPyTool::shutdown)
+
+ - ICallGraphBuilderSvc : the interface to the service building a callgraph out of the sequence of @c Algorithm. It is a rather <i>'work in progress'</i> class at the moment (June 2007) and not (yet) officially part of the toolkit of the Performance Monitoring domain. The main idea is to use the Gaudi @c IAuditor infrastructure to monitor algorithms/services and later on attach to each of the nodes of the callgraph additional informations (CPU, memory consumption,...).
+
+@ref used_PerfMonKernel
+
+@ref requirements_PerfMonKernel
+
+*/
+
+/**
+@page used_PerfMonKernel Used Packages
+@htmlinclude used_packages.html
+*/
+
+/**
+@page requirements_PerfMonKernel Requirements
+@include requirements
+*/
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.