diff options
Diffstat (limited to 'TAO/orbsvcs/lib/RtecScheduler.idl')
-rw-r--r-- | TAO/orbsvcs/lib/RtecScheduler.idl | 222 |
1 files changed, 0 insertions, 222 deletions
diff --git a/TAO/orbsvcs/lib/RtecScheduler.idl b/TAO/orbsvcs/lib/RtecScheduler.idl deleted file mode 100644 index e0d2ea9fa0f..00000000000 --- a/TAO/orbsvcs/lib/RtecScheduler.idl +++ /dev/null @@ -1,222 +0,0 @@ -// -// $Id$ -// - -module RtecScheduler { - - // TODO: Use the COS Time Service TimeT type. - typedef double Time; - typedef long Period; - typedef Time Quantum; - - const long NO_QUANTUM = 0; - - // - // TODO: This differ from the ones documented in the TAO paper, - // namely: - // INTERRUPT - // IO_SERVICE - // CRITICAL - // HARD_DEADLINE - // BACKGROUND - // Notice that the order is inverted and, of course, the names don't - // match. - // - enum Importance { - VERY_LOW, - LOW, - MEDIUM, - HIGH, - VERY_HIGH - }; - - typedef long handle_t; - // RT_Info's are assignned per-application unique identifiers. - - struct Dependency_Info { - long number_of_calls; - handle_t rt_info; - // Notice the reference to the RT_Info we depend on. - }; - - typedef sequence<Dependency_Info> Dependency_Set; - - typedef long OS_Priority; - typedef long Sub_Priority; - typedef long Preemption_Priority; - - struct RT_Info - // = TITLE - // Describes the QoS for an "operation". - // - // = DESCRIPTION - // The CPU requirements and QoS for each "entity" implementing - // an application operation is described by the following - // information. - { - // Application defined string that uniquely identifies the - // operation. - string entry_point; - - // The scheduler defined unique identifier. - handle_t handle; - - // Execution times - Time worst_case_execution_time; - Time typical_execution_time; - - // To account for server data caching. - Time cached_execution_time; - - // For rate operations this defines the period of the rate. - // 0 means "completely pasive", i.e., this operation only executes - // when called. - Period period; - - // Operation importance (used to "break ties"). - Importance importance; - - // For time-slicing (for BACKGROUND operations only). - Quantum quantum; - - // The following attributes are defined by the Scheduler once the - // off-line scheduling is computed. - - // The number of threads that will execute this operation? - // TODO: clarify this. - long threads; - - // The operations we depend upon. - Dependency_Set dependencies; - - // The OS por processing the events generated from this RT_Info. - OS_Priority priority; - - // For ordering RT_Info's with equal priority. - Sub_Priority subpriority; - - // The queue number for this RT_Info. - Preemption_Priority preemption_priority; - }; - - exception DUPLICATE_NAME {}; - // The application is trying to register the same task again. - - exception UNKNOWN_TASK {}; - // The RT_Info handle was not valid. - - exception NOT_SCHEDULED {}; - // The application is trying to obtain scheduling information, but - // none is available. - - exception UTILIZATION_BOUND_EXCEEDED {}; - exception INSUFFICIENT_THREAD_PRIORITY_LEVELS {}; - exception TASK_COUNT_MISMATCH {}; - // Problems while computing off-line scheduling. - - typedef sequence<RT_Info> RT_Info_Set; - - // TODO: Find a reasonable name for this interface, maybe we should - // change the name of the module to RtecSchedulerAdmin and name this - // Scheduler - interface Scheduler - // = DESCRIPTION - // This class holds all the RT_Info's for a single application. - // During the configuration run this will be implemented as a - // single remote object, whose services are used by the - // suppliers, consumers and the EC. - // At run-time each process will hold a copy of the compiled - // version of the Scheduler, using the precomputed data to - // resolve requests (avoiding any remote calls) and ignoring any - // requests for modifying its state. - // A Factory class will be used to choose the proper - // implementation. - // - // This class must be registered with the naming service using a - // well known name ("Scheduler" seems the obvious choice), the - // Naming Context will account for different applications and - // modes. - // - // Once the scheduling data is computed it can be retrieved - // remotely to generate the code for the run-time version. - { - handle_t create (in string entry_point) raises (DUPLICATE_NAME); - // Creates a new RT_Info entry for the function identifier - // "entry_point", it can be any string, but the fully qualified - // name function name is suggested. - // Returns a handle to the RT_Info. - - handle_t lookup (in string entry_point); - // Lookups a handle for entry_point. - // TODO: Should we add INVALID_HANDLE or raise an exception? - - RT_Info get (in handle_t handle) raises (UNKNOWN_TASK); - // Retrieve information about an RT_Info. - - void set (in handle_t handle, - in Time time, - in Time typical_time, - in Time cached_time, - in Period period, - in Importance importance, - in Quantum quantum, - in long threads) - raises (UNKNOWN_TASK); - // Set the attributes of an RT_Info. - // Notice that some values may not be modified (like priority). - - void add_dependency (in handle_t handle, - in handle_t dependency, - in long number_of_calls) - raises (UNKNOWN_TASK); - // Adds <dependency> to <handle> - - void priority (in handle_t handle, - out OS_Priority priority, - out Sub_Priority subpriority, - out Preemption_Priority p_priority) - raises (UNKNOWN_TASK, NOT_SCHEDULED); - void entry_point_priority (in string entry_point, - out OS_Priority priority, - out Sub_Priority subpriority, - out Preemption_Priority p_priority) - raises (UNKNOWN_TASK, NOT_SCHEDULED); - // Obtain the run time priorities. - // TODO: Do we need the two interfaces or is it simply confusing? - // If we should to keep only the <handle> version: Are the extra - // round-trips too expensive? - // If we choose only the <entry_point> version: Are the copies for - // the string affordable? - - void compute_scheduling (in long minimum_priority, - in long maximum_priority, - out RT_Info_Set infos) - raises (UTILIZATION_BOUND_EXCEEDED, - INSUFFICIENT_THREAD_PRIORITY_LEVELS, - TASK_COUNT_MISMATCH); - // Computes the scheduling priorities, returns the RT_Info's with - // their priorities properly filled. - // This info can be cached by a Run_Time_Scheduler service or - // dumped into a C++ file for compilation and even faster (static) - // lookup. - - // TODO: The dependencies field can be removed from the RT_Info - // and made part of the secrets of "Application", adding the - // following to satisfy curious clients: - // - // struct Dependency { - // long number_of_calls; - // handle_t dependency; - // }; - // typedef sequence<Dependency> Dependency_Set; - // - // Dependency_Set dependencies (in handle_t handle) - // raises (UNKNOWN_TASK); - // Returns the list of dependencies - // - // long number_of_dependencies (in handle_t handle) - // raises (UNKNOWN_TASK); - // Returns the number of dependencies. - - }; -}; |