Why some ports are not triggered in Reo Animation and dose not exist in Extended Automata

[Alireza Farhadi]

Dear Member,

In continue of my dining philosopher orchestration network, I have designed a connector that decide to call release port of allocated fork components based on release request which is raised by a philosopher at end of eating phase with those forks. 

In this section my connector must detect which fork must be released and this evaluation take placed by a SychDrain channel that has an equality check between a take fork request (this request is initiated form take requests of a philosopher and it is passed trough a router node which simulates fork selection) and release request of a philosopher.

My problem is when ECT generates animation of this network (all stuff will be attached), the take_request tokens do not reach to mentioned SyncDrains. This means my connector dose not accept any release request and this are reflected in generated extended automata with no occurrence of any release_request node. 

How can I fix this defects because I intend that the release detector connector checks equality between release request token value and selected take fork request token value that come from philosopher after a time for eating phase which are shown by a fifo1 channel and if this equality exists then trigger fork by corresponding release node.

Regards,

Alireza Farhadi

[Christian Krause]

Hi Alireza,

the two SyncDrains at P0 and P1 will definitely not be able to fire.
Let's look at the incoming channels at the left-hand side of P0 for now:
you have two Transform channels from "release_request_phil0" to R0 and
R1, and two Sync channels from R0 and R1 to P0. All involved nodes have
standard Reo semantics: merge at the incoming ends and replicate at the
outgoing ends. All involved channels are synchronous. That means the
following:

1) data items arriving at "release_request_phil0" are replicated to both
Transform channels
2) the two data items are *synchronously* transformed and sent to R0 and R1
3) both R0 and R1 *synchronously* accept the data items and replicate
them to the Syncs
4) both Sync channels send the data items *synchronously* to P0

At this very point, the problem occurs: P0 wants to merge incoming data
items. This means it allows data flow from one of the incoming two Sync
channels at a time, but not both! P0 mutually excludes dataflow from the
two Syncs. Therefore, you do not get any dataflow at all. If you try to
generate animations for just these four channels and four nodes, you
will also get no animations.

There are a number of possible solutions to this problem, depending on
your requirements to the connector. Here are three that came to my mind:

- You change the type of "release_request_phil0" to "route" (XOR
semantics). Then only one path is chosen at a time. Or:
- You substitute the Sync channels by LossySync channels (be careful
with the difference in the semantics of CA and colorings/animations!). Or:
- You change the type of P0 to "join". But this is probably not want you
want because then the produced data item will be a pair of the data
items from R0 and R1.

I hope this helps.

cheers,
Christian

> --
> You received this message because you are subscribed to the Google
> Groups "reo-dev" group.
> To post to this group, send email to reo...@googlegroups.com.
> To unsubscribe from this group, send email to
> reo-dev+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.