diff options
Diffstat (limited to 'TAO/orbsvcs/orbsvcs/Event/README')
| -rw-r--r-- | TAO/orbsvcs/orbsvcs/Event/README | 146 |
1 files changed, 0 insertions, 146 deletions
diff --git a/TAO/orbsvcs/orbsvcs/Event/README b/TAO/orbsvcs/orbsvcs/Event/README deleted file mode 100644 index 75497bec2a7..00000000000 --- a/TAO/orbsvcs/orbsvcs/Event/README +++ /dev/null @@ -1,146 +0,0 @@ -# $Id$ - - The new implementation of the Event Channel - -= Abstract - - The current implementation of TAO's real-time Event Channel -has proven to be efficient, generally reliable and in general does bug -free; but it was designed to solve the forces in one problem domain -(hard real-time avionics), so performance considerations (latency) -were the main concern over other requirements. - A new implementation of the real-time Event Channel is -proposed that will preserve the performance of the the original event -channel, yet it will be properly strategized so it can be adapted and -extended to other domains (such as distributed interactive -simulation). - -= The module architecture - - The current event channel is based on a series of modules -organized in a stack, each module is supposed to execute a single -task, for instance correlation; and could potentially be extracted or -replaced to adapt the EC to new requirements. Unfortunately the -modules keep explicit references to the modules above them and below -them, including the exact type of the module. Even though adding base -classes to represent the modules in a generic way would solve the -syntactic problems of this architecture, the relation between the -modules have semantic significance and they cannot simply be organized -in an arbitrary way; even more, we have found that only a few -operations on each module need to be strategized, and that using -Template Methods or strategies on each module would be a better -solution than to replace the module wholesale. - - The new Event Channel will consist of the following -components: - -- The Filter object: each consumer will have a filter object, this - filters are organized in a hierarchical structure, for instance a - disjunction filter has N children and accepts an event if any of its - children do, in contrast a conjunction filter will wait until all - its children have accepted the event. - The filter hierarchy for a particular consumer is created using - the Builder pattern, i.e. a separate class creates the hierarchy - from the ConsumerQOS specification. The user can add new filtering - strategies (such as "wait until this events arrive in this - sequence" or "do not accept events from this source") by providing a - new filter and a new Filter_Builder objects. - Notice that the per-consumer filters were already present in the - old event channel, the main difference is that all events went - through the correlation module, in many cases just to check that the - consumer did not require correlation; the new scheme will eliminate - that extra test. More importantly, if the event was accepted a - ACE_ES_Dispatch_Request was dynamically allocated and passed to the - dispatching module; this was necessary because some implementations - of the dispatching module required to enqueue the event. Clearly - the allocation of some node for the queue is a decision better left - for the dispatching module, thus avoiding memory allocations in the - single threaded case. - Another importat feature of this design is that in the case where - the consumer only has disjunctive filtering no copies of the data - are needed (until we arrive to the dispatching module). - - This filter objects can also be used to strategize the priority - assignment in conjuctive and disjunctive correlations. - -- The dispatching module: as in the original event channel - implementation there are multiple ways to dispatch events, this - feature is preserved with only a few syntactic changes. - -- The ConsumerAdmin module: this object acts as a factory for the - ProxyPushSupplier objects (i.e. the interface between the event - channel and its consumers); the object delegates on the event - channel implementation to create the objects, and provides a simple - mechanism to control the object activation in different POAs: it - queries the Event Channel for the right POA to use. - -- The SupplierAdmin module: this is a factory for the - ProxyPushConsumer objects (again delegating on the event channel); - it also provides the user with control over the proxy activation. - It provides two template method that can be used to: - + Inform all supplier that a consumer has connected/disconnected. - + Inform only the suppliers that are publish the events in the - consumer. - + Do not inform the suppliers. - - -- The ProxyPushSupplier object delegates on the filter to do most of - its job, but it can be subclassed to provide event counting and - similar features. Notice that providing the Supplier with a - Null_Filter moves all the filtering responsability - -- The ProxyPushConsumer object can be subclassed to provide different - strategies to handle filtering, for instance: - + Each one keeps track of the consumers possibly interested in - the events published here. - + Use the global consumer list to find objects interested in the - current event - + Use a global list for each type of event. - + Do not use a global list and let the consumers do filtering (if - they want to) - [NOTE: we are considering if this features should be implemented as - strategies instead of template method, if implemented as factory - methods we may need to use decorators to handle other sources of - variation, such as event counting; using an strategy decreases the - performance (slightly) in the common case where no other features - are required] - -- The Timer_Module: this is used by the EC_Filter_Builder to create - per-consumer timeout events. - -- The Event_Channel: this class acts as a mediator between the - components above. It is completely strategized by an abstract - factory (EC_Factory) that creates each one of the objects already - described, in fact, the factory methods in the Event Channel are - implemented as simple delegation on the EC_Factory. - -- The EC_Factory: using this class the user can strategize and control - all the object creations in the EC; notice that this is an abstract - factory because not all the combinations of the classes described - make sense. - - -= Performance - - The main sources of overhead in the EC are: - - - Locking - - Memory allocation - - Data copying - - the new design do not neglect this issues, for instance: - - - The EC_Factory creates strategized locks, so the single threaded - implementations can perform correctly. - - Most of the classes have *no* internal locks, thus a single lock - can be shared in the critical path. - - Each consumer has its own filters, so no locking is required at - each filter (just one for the consumer). - - In the common case data can be pushed from the original supplier - to the dispatching module without any data copies or memory - allocations, at that point the dispatching module can make the - copies it deems necessary to push the data ahead. - - The filtering mechanism will provide two data paths, one for the - data that is owned by the filter (and thus require no copying) and - one for external data; this will be used in the dispatching module - to minimize data copying too. |