how to build a Reo connector from a constraint automata

[Alireza Farhadi]

Dear Members,

Because I could not to build a Reo network for my release fork detector in modified dining philosopher, at first I preferred to draw ideal release detector automata, so I have drawn a constraint automata in ECT and I want to build an equivalent Reo connector with that behavior.

My mentioned constraint automata has only one inital state and 2 transitions to self and its alphabet(names) number is 6 {REL_REQ0,REL_REQ1,TAK_FRK0,REL_FRK0,TAK_FRK1,REL_FRK1}. also the constraint automata has 2 transitions:

transition1:

names:

{REL_REQ0,TAK_FRK0,REL_FRK0,TAK_FRK1,REL_FRK1},

constraint:

((TAK_FRK0==0 & TAK_FRK0!=1 & TAK_FRK0!=2 & TAK_FRK0!=3 & REL_FRK0=TAK_FRK0 & TAK_FRK1!=0 & TAK_FRK1==1 & TAK_FRK1!=2 & TAK_FRK1!=3 & REL_FRK1=TAK_FRK1) | (TAK_FRK0!=0 & TAK_FRK0==1 & TAK_FRK0!=2 & TAK_FRK0!=3 & REL_FRK0=TAK_FRK0 & TAK_FRK1==0 & TAK_FRK1!=1 & TAK_FRK1!=2 & TAK_FRK1!=3 & REL_FRK1=TAK_FRK1))

transition2:

names:

{REL_REQ1,TAK_FRK0,REL_FRK0,TAK_FRK1,REL_FRK1}

constraint:

((TAK_FRK0!=0 & TAK_FRK0!=1 & TAK_FRK0==2 & TAK_FRK0!=3 & REL_FRK0=TAK_FRK0 & TAK_FRK1!=0 & TAK_FRK1!=1 & TAK_FRK1!=2 & TAK_FRK1==3 & REL_FRK1=TAK_FRK1) | (TAK_FRK0!=0 & TAK_FRK0!=1 & TAK_FRK0!=2 & TAK_FRK0==3 & REL_FRK0=TAK_FRK0 & TAK_FRK1!=0 & TAK_FRK1!=1 & TAK_FRK1==2 & TAK_FRK1!=3 & REL_FRK1=TAK_FRK1))

I guess resulted Reo connector have 4 input port{REL_REQ0,REL_REQ1,TAK_FRK0,TAK_FRK1} and 2 output port{REL_FRK0,REL_FRK1} and when the port REL_REQ0 is enabled and ports (TAK_FRK0==0 and TAK_FRK1==1) or (TAK_FRK0==1 and TAK_FRK1==0) then corresponding output ports REL_FRK0,REL_FRK1 are enabled. this condition is true for the port REL_REQ1 if we have (TAK_FRK0==2 and TAK_FRK1==3) or (TAK_FRK0==3 and TAK_FRK1==2).

In the other hand I face to a ambiguity when 2 nodes REL_REQ0,REL_REQ1 are enabled simultaneously. How this situation must be handled in resulted Reo connector?

mentioned .ea and .png are found in attachments.

Regards,

Alireza Farhadi

[Christian Krause]

Alireza,

sorry, I did not exactly understand how the connector should behave. I guess you don't need any FIFOs because your automaton has only one state. I can maybe help you if you either simplify the automaton (it is not minimal in the sense that the constraints contain redundant inequality checks) or if you shortly explain again the intended behavior of the connector informally. Also it would be helpful if you say something about the intended dataflow directions (this cannot easily inferred from a CA).

cheers,
christian

Dear Members,

Regards,
Alireza Farhadi

--
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.

[Alireza Farhadi]

Dear Christian,

I'm sorry for asking unclear question.

Simple constraint automata with removing redundant inequalities and equalities is:

One state q0 and two transition to self:

transition1:
names:
{REL_REQ0,TAK_FRK0,REL_FRK0,TAK_FRK1,REL_FRK1},
constraint:

(((TAK_FRK0==0 & TAK_FRK1==1) | (TAK_FRK0==1 & TAK_FRK1==0)) & (REL_FRK1=TAK_FRK1 & REL_FRK0=TAK_FRK0))

transition2:
names:
{REL_REQ1,TAK_FRK0,REL_FRK0,TAK_FRK1,REL_FRK1},
constraint:

(((TAK_FRK0==2 & TAK_FRK1==3) | (TAK_FRK0==3 & TAK_FRK1==2)) & (REL_FRK1=TAK_FRK1 & REL_FRK0=TAK_FRK0))

informal behavior of this automata can be explained with this: when release_request0 (REL_REQ0) is arrived if input ports: take_fork0 and take_fork1 tokens have values of "0" and "1" or in reverse "1" and "0" then output port release_fork0 has take_fork0 token value and also release_fork1 has take_fork1 token value. For other release_request1, we have same behavior except for static integers that are replaced with "2" and "3".

I hope to explain clearly. As I mentioned before I'm worry about simultaneous coming of  2 release_requests and how to prevent this situation in synthesized Reo network.

Regards,

Alireza Farhadi

[Christian Krause]

Hi Alireza,

I drew a connector (see the attachment). The conversion to CA currently
does not work for this connector because the SyncDrain constraints
cannot be parsed. Anyway, I think the solution is in general not ideal
because you have very similar cases for different data values which have
to be treated separately. Maybe you can think of another way of doing
it. If not, and you need data constraint5s as I used in the connector,
let me know and I can see if it is difficult to support nit in the CA
converter.

Ciao,
Christian

> <mailto:reo...@googlegroups.com>.

> To unsubscribe from this group, send email to
> reo-dev+u...@googlegroups.com

> <mailto:reo-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
> --
> 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

> <mailto:reo...@googlegroups.com>.

> To unsubscribe from this group, send email to
> reo-dev+u...@googlegroups.com

> <mailto:reo-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
>
> --
> 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.

--
Christian Krause
Hasso Plattner Institute for Software Systems Engineering
Prof.-Dr.-Helmert-Str. 2-3
D-14482 Potsdam, Germany

Phone: +49 (0)331-5509-525

[Alireza Farhadi]

Dear Christian,

Your solution was very useful for me,  I think that my dining philosopher orchestration network works well, Thanks A Lot.

Now, I feel that understand behavior of Reo channels and nodes, properly. For example I was thinking before, a replicator node can select non-deterministic-ally one of input channel but when I connected two input channels with same source node (but with different token value because of existence of transfer channel), this replicator node doesn't work anymore but there are still some questions like this:

Is that correct to say about the replicator behavior?: if and only if one of input channel is active then this channel is copied to all of output channels instead of non-deterministic selection because node never select so if above condition is satisfied then act.

By the way, as you mentioned about Sync-Drain constraint that are not supported in CA generation, what about filter and transform channel constraint, I thought that filter and transform channel constraint appear in generated CA, I guess. Am I right?

Regards,

Alireza Farhadi

   <mailto:reo-dev@googlegroups.com>.

   To unsubscribe from this group, send email to

   reo-dev+unsubscribe@googlegroups.com

   <mailto:reo-dev%2Bunsubscribe@googlegroups.com>.

   For more options, visit this group at
   http://groups.google.com/group/reo-dev?hl=en.

   --
   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

   <mailto:reo-dev@googlegroups.com>.

   To unsubscribe from this group, send email to

   reo-dev+unsubscribe@googlegroups.com

   <mailto:reo-dev%2Bunsubscribe@googlegroups.com>.

   For more options, visit this group at
   http://groups.google.com/group/reo-dev?hl=en.


--
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+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/reo-dev?hl=en.

--
Christian Krause
Hasso Plattner Institute for Software Systems Engineering
Prof.-Dr.-Helmert-Str. 2-3
D-14482 Potsdam, Germany

Phone: +49 (0)331-5509-525

--
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+unsubscribe@googlegroups.com.

[Christian Krause]

Alireza,
please read on...

On 10/12/11 17:15, Alireza Farhadi wrote:
> Dear Christian,
>

> Your solution was very useful for me, I think that my dining
> philosopher orchestration network works well, Thanks A Lot.
>
> Now, I feel that understand behavior of Reo channels and
> nodes, properly. For example I was thinking before, a replicator node
> can select non-deterministic-ally one of input channel but when I
> connected two input channels with same source node (but with different
> token value because of existence of transfer channel), this replicator
> node doesn't work anymore but there are still some questions like this:

Reo nodes (both "replicate" and "route" nodes) merge incoming data
items. That means that they allow dataflow at only one of the incoming
channels at a time. If that is not possible (due to some other
constraints) then dataflow through the node is not possible at all. For
example, consider two nodes A and B (both normal "replicate" nodes) and
assume that there are *two* Sync channels from A to B. Then A tries to
replicate data to *both* Sync channels, where as B allows only dataflow
from *one* of them. Since neither the Syncs nor the nodes buffer or lose
data items, the only solution is to allow no dataflow at all (informally
speaking...)

>
> Is that correct to say about the replicator behavior?: if and only if
> one of input channel is active then this channel is copied to all of
> output channels instead of non-deterministic selection because node
> never select so if above condition is satisfied then act.
>

Assume that a node X has two inputs A and B. Then X enforces the
following constraint: either there is flow at A and no flow at B, or the
other way around. Essentially, X mutually excludes dataflow from A and B
(like a logical XOR).

> By the way, as you mentioned about Sync-Drain constraint that are not
> supported in CA generation, what about filter and transform channel
> constraint, I thought that filter and transform channel constraint
> appear in generated CA, I guess. Am I right?
>

Yes, but the converter from Reo to EA has some flaws and may not accept
all constraints that you specify. Simple comparisons or assignments
should work though.

> Regards,
> Alireza Farhadi

Cheers,
Christian

> <mailto:C.Kr...@cwi.nl> <mailto:C.Kr...@cwi.nl

> <mailto:C.Kr...@cwi.nl>>> wrote:
>
> Alireza,
>
> sorry, I did not exactly understand how the connector should
> behave. I guess you don't need any FIFOs because your automaton
> has only one state. I can maybe help you if you either simplify
> the automaton (it is not minimal in the sense that the constraints
> contain redundant inequality checks) or if you shortly explain
> again the intended behavior of the connector informally. Also it
> would be helpful if you say something about the intended dataflow
> directions (this cannot easily inferred from a CA).
>
> cheers,
> christian
>
> ----- Original Message -----
> From: "Alireza Farhadi" <alireza...@gmail.com

> <mailto:alireza...@gmail.com>
> <mailto:alireza...@gmail.com <mailto:alireza...@gmail.com>>>
> To: reo...@googlegroups.com <mailto:reo...@googlegroups.com>

> <mailto:reo...@googlegroups.com>
> <mailto:reo...@googlegroups.com <mailto:reo...@googlegroups.com>>.

>
> To unsubscribe from this group, send email to

> reo-dev+u...@googlegroups.com
> <mailto:reo-dev%2Bunsu...@googlegroups.com>
> <mailto:reo-dev%2Bunsu...@googlegroups.com
> <mailto:reo-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
> --
> 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

> <mailto:reo...@googlegroups.com>
> <mailto:reo...@googlegroups.com <mailto:reo...@googlegroups.com>>.

>
> To unsubscribe from this group, send email to

> reo-dev+u...@googlegroups.com
> <mailto:reo-dev%2Bunsu...@googlegroups.com>
> <mailto:reo-dev%2Bunsu...@googlegroups.com
> <mailto:reo-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
>
> --
> 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

> <mailto:reo...@googlegroups.com>.

> To unsubscribe from this group, send email to

> reo-dev+u...@googlegroups.com
> <mailto:reo-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
>
>
> --

> Christian Krause
> Hasso Plattner Institute for Software Systems Engineering
> Prof.-Dr.-Helmert-Str. 2-3
> D-14482 Potsdam, Germany
>
> Phone: +49 (0)331-5509-525
>
>
> --
> 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

> <mailto:reo...@googlegroups.com>.

> To unsubscribe from this group, send email to

> reo-dev+u...@googlegroups.com
> <mailto:reo-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/reo-dev?hl=en.
>
>
> --
> 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.