Overview
In the most general case, connections link array objects and are therefore themselves arrays. The precise mapping of elements in the consumer to elements in the provider is determined by the connection mapping and in most cases the generated default is correct, but in more advanced cases you will need to modify the connection mapping.
There are three categories of connection:
- Standard
- Regular
- Irregular
'Standard' connections are those that use the default set of rules for mapping between multi-dimensional objects; most connections are actually standard. 'Regular' connections are those that can be described by a mapping, but one which does not follow the standard rules and must therefore be entered by the user. 'Irregular' connections are those that cannot be described by a mapping and so each element pair needs to be individually specified.
The precise mapping of elements in the consumer to elements in the provider is determined by the connection mapping. In the example above, the store is two dimensional with 'M' the most rapidly varying index. This could be visualized as a 2-d matrix with 'N' rows and 'M' columns. By default, each element of the left hand collector will collect one row containing 'M' elements and each element of the right hand collector will collect one column containing 'N' elements.
Mapping Attributes
All connections can have a 'dimension', and a 'signature', and some can also have a 'repeat count'.
Dimensions
If the connection is standard, then this attribute describes the dimensionality of the connection array that is owned by each element of the consumer. So if an [N] element store is connected to an [N] element collector then this would be [1] because by default, each consuming collector element would have one connection to its reciprocal providing store element. If on the other hand, the store had [N][M] elements, and the collector had [N] elements then the connection dimensionality would be [M] because the 'N' dimension will cancel between the consumer and the provider and each collector element would map to 'M' store elements.
Repeat Count
If the connection is standard then this attribute determines the number of times that each connection element is repeated. Non unity repeat counts are only valid if the consumer is a collector or a multiplexor; or if the connection is 'manual'.
Signature
If the connection is standard or regular then this logical string defines the connection mapping between consumer and provider elements and will be used by the translator to generate runtime connection code.
Standard Connections
The following examples illustrate the 'standard' connection rules:
One-to-One
In the example above, one collector element connects to one store element.
One-to-Many
In the example above, one collector element collects [N] store elements.
Many-to-Many (Same Dimensions)
In the example above, each collector element collects one store element.
Many-to-One
In the example above, each element of the collector connects to the single element of the store. This is therefore a competing connection.
Many-to-Many (Common Dimension)
In the example above, the '[N]' dimension is common to both the consumer and the provider and can therefore be 'cancelled'. The result is that each element of the collector, collects [M] store elements.
Many-to-Many (Different Dimensions)
In the example above, each element of the collector, collects all [M] elements of the store. This means that each of the collector's 'N' elements are in competition for each element of the store (an unlikely requirement).
One-to-One (Repeated)
In the example above, the single collector element connects to the single store element 'R' times. This means that will attempt to open the store 'R' times. Note that this would always block unless the store had at least [R] buffers.
Many-to-Many (Repeated, Different Dimensions)
In the example above, each collector element connects to each store element 'R' times. So each collector element makes 'RxM' connections and each store element is connected to 'RxN' times.
One-to-Many Restrictions
The example above attempts to connect the distributor element 'N' times; once to each store element. This is illegal. Only collector and multiplexor elements can consume from multiple providers. There is no limit however, on the number of consumers that can connect to a particular provider element.
Many to One Connections
There are two types of many to one connections, and both are required for general parallelism.
Single Provider/ Multiple Consumers
Multiple consumers can either share their provided events, in which case they all have access to the same events, or they can compete for them, in which case they each receive distinct events.
There are four cases where events are shared. Distributors are the most common mechanism and have the property that events will be buffered so that they are delivered at the rate of the slowest consumer. Multiple consumers requesting from logical semaphores can also be unblocked by the same signal. Multiple consumers requesting 'read' access to arbitrated stores will also share events, and the same is true for multiple consumers waiting for arbitrated store update notification.
In all other cases, events are 'competed-for'. This means that each consumer will receive distinct events, and these will be provided to consumers on a first-come first-served basis. Competed connections are often used as a means of creating scale-able applications that discover available CPUs at runtime. It is often the case that the shared and competed schemes are mixed; and an example would be a distributed event that is consumed by a competer object that has multiple consumers.
The delivery of logical semaphore and arbitrated store events is not guaranteed and if this is required then distributors can be used to ensure that all consumers receive consistent event streams. In the first example below, some reading method elements could miss an event if they spent too long processing an earlier event. In the second example, a distributor is used to ensure that they all receive an identical event stream.
Single Consumer / Multiple Providers
There are three cases where a single consumer can be connected to multiple providers. Collectors consume multiple events, and when they have all been received, provide them as a single compound event. Multiplexors consume multiple events in parallel, but provide each event individually.
Active object elements (methods, threads and circuits) can all own manual connections, and each connection element can be 'repeated' allowing the active object to open sequences of events from a single provider element simultaneously.