Description
Multiplexors (MPXs) can be thought of as logical OR gates, and any event retrieved by the consuming face (shown on left), is immediately delivered to the providing face (shown on right). As with all consuming objects, consumed events can be atomic or compounded. Multiplexors are frequently used as means of serializing parallel event streams or as an equivalent to 'WaitForMultipleObjects' or 'Select' functions.
CDL supports two forms of multiplexing. In the 'regular' case, consumed events are assumed to have a common form, and are all handled in the same way. This means that regular multiplexed events do not need to be de-multiplexed, and methods that handle them only have a single entry point which is called for all events. Regular multiplexing does not require connection labelling but does require each connected provider to have the same event tree structure and data content. Since multiplexors only return a single event, access functions can return multiplexed events without specifying a multiplexed link number (see Multiplexor Connections).
The irregular case assumes that each connection's events require specific treatment, even if they do in fact have a common structure and content. This distinction is elaborated upon in the Multiplexor Connections topic.
Creation Attributes
Name
Instance name (see Object Names)
Dimensions
Instance dimensionality (see Object Dimensionality)
Presence
Instance presence flag (see Object Presence)
Reentrancy
Instance reentrancy (see Object Reentrancy)
Visibility
Instance visibility flag (see Object Visibility)
Request Mode
This attribute determines whether the multiplexor uses 'round-robin' or 'prioritized' request scheduling. In the round-robin case the requesting link number is incremented after each request, and wraps back to the first link after requesting from the first. In the prioritized case, each link is given a priority at connection time. In this case highest priority links request first. If all links of a given priority are blocked, then the multiplexor will use links at the next highest allocated priority. Zero is the lowest priority.
Connection Attributes
Event propagator objects have two types of connection. Those that provide events to their consuming faces, and those that consume events from their providing faces. The attributes associated with any particular connection therefore depend on the providing and consuming object types (see Automatic Connections).
All automatic connections require;
Timeout
This attribute determines whether the connection will poll or block (see Connection Timeout).
Signature
This attribute is a string that describes the mapping from elements in the consumer, to elements in the provider. See Connection Mappings.
Dimensions
This attribute determines the dimensionality of the connection array owned by each consuming element. By default, this will provide the consuming element with one connection for each provider element. Collector, Multiplexor and Manual connection consumers can have multi-dimensional connection arrays, but in all other cases, this attribute will be '1'. See Connection Mappings.
Repeat Count
This attribute determines the number of times that each 'provider element to consumer element' connection is repeated. If the repeat count is greater then one, then the Dimensions attribute (above), and the resulting connection access functions, will both have an 'extra' dimension. Only Collector, Multiplexor and Manual connection consumers can have repeat counts that are greater than '1'. See Connection Mappings.
Name
This attribute determines the connection's 'name' which is used to construct access function names (see Connection Names).
There are three specific attributes required for connections that provide events to a multiplexor's consuming face.
Priority
This attribute is only required for connections involving 'prioritized' multiplexors (see above). Links with numerically greater priorities issue requests before links with numerically lesser priorities.
Connection label
This attribute uniquely identifies each multiplexor connection and is referenced by reciprocal demultiplexor connections.
There are no specific attributes required for connections that consume events from a multiplexor's providing face.
Manual Connections
Manual connections provide a means of directly accessing target objects. These are created automatically from CDL diagrams and accessed using their access function names (see Manual Connections).
Multiplexor connections provide the following member functions;
WaitEvent()
This member function issues an 'open' request to the multiplexor (see MPX WaitEvent function).
Close()
This member function closes a previously opened multiplexor (see MPX Close function).
Automatic and Manual Connections
The following member functions can be used to retrieve information from both automatic and manual connections;
IsOpen()
This member function returns TRUE if the connection is 'Open' or FALSE otherwise.
EventNum()
This member function returns the retrieved event's sequence number. Numbering starts from zero (the first retrieved event).
NumCxns()
This member function returns the number of multiplexed connections (which can themselves be multi-dimensional).
CxnNum()
This member function returns the retrieved event's connection number.
ElemNum()
This member function returns the retrieved event's element number. In the case of multidimensional connections, this will be the particular element within the the multi-dimensional connection. In the case of scalar connections, this will always therefore be 0.
'Label'_CxnNumber()
In addition to the above member functions, the translator also generates functions that allow each connection's enumerated label to be returned. This allows the user code to determine which logical connection has retrieved an event. The function name is constructed from the connection's label name with "_CxnNumber" appended.
LinkNum()
This member function returns the multiplexor's retrieving link number. Each connection element has a unique link number which is determined by the order that the connection element was connected to the multiplexor.
Notes
Multiplexors are implicitly reentrant in the sense that each link can be opened simultaneously. However, if the reentrancy is greater than one, then each link can itself be simultaneously opened 'reentrancy' times.
Multiplexors should never request with a polling timeout as this will cause them to race.
If de-multiplexed, all objects between the demultiplexor and the event provided to the multiplexor are implicitly transparent and cannot be referenced by the consumer.
If not de-multiplexed, irregular multiplexors typically need to be 'opaque' since their retrieving link information is usually required.
Multiplexing/De-multiplexing and Collecting/Splitting; are nestable operations.
Example
See Multiplexing, Overloading and Shared State.