Execution Trace of Dreams for reliable LossySync

3 views
Skip to first unread message

Alireza Farhadi

unread,
May 15, 2012, 9:43:55 AM5/15/12
to reo...@googlegroups.com
Dear Members, (Specially  Dr. Jose Proenca' )

I recently focus on distributed implementation of Reo in Dreams framework based on Dr. Jose Proenca's PhD thesis

There is an example in section 7.4.1 named reliable LossySync connector that acts like a Sync channel. Figure 7.4 of mentioned connector is attached. My question is around of trace execution of this connector depicted in Figure 7.5 (also attached). There is a description of what happened in this execution trace in page 193. According that the actor named x that corresponds to node x in the Reo connector must process received messages in order that they were sent but we see in the top rectangle below the actor x send requests to neighbors in the reverse order of receipt.

The next issue in the continue is in the description of execution trace mentioned after the node x actor received Req(2) message from the lossy channel actor then x actor replies lossy actor by sending Busy message. I can't find this event in the Figure 7.5.

For last question, Example 6.3.5. in the page 150 is used for showing why the actor of LossySync channel with input port c and output port d is not a proactive actor, so it refers to Figure 6.4 on the left (attached). For the proving, it is shown none of two port are not proactive. This means two ports can not be value independent from all others in an atomic step of a transition, therefor, it is assumed that if we have two value v and w from domain D and are not equal to each other then we have a transition from state q to itself by label l3(v) where the value v flows through the port c and another transition from q to itself with l3(w) where the value w flows through the port d, but we have not a label named l which contains an atomic step such that v flows through c and w flows through d.

For proving in the above I think concentration is on the synchronous behavior of LossySync channel but when LossySync act like a barrier so we use l4(w) for showing proactive nature of LossySync actor based on related definition. Am I correct in this view?

Regards,
Alireza Farhadi
Figure7.4-reliableLossySync.PNG
Figure7.5-executionTraceOfReliableLossySync.PNG
Figure6.4(right)BehaviouralAutomataLossySync.PNG

José Proença

unread,
May 15, 2012, 3:28:44 PM5/15/12
to reo...@googlegroups.com
Dear Alireza Farhadi,


> There is an example in section 7.4.1 named reliable LossySync connector that acts like a Sync channel. Figure 7.4 of mentioned connector is attached. My question is around of trace execution of this connector depicted in Figure 7.5 (also attached). There is a description of what happened in this execution trace in page 193. According that the actor named x that corresponds to node x in the Reo connector must process received messages in order that they were sent but we see in the top rectangle below the actor x send requests to neighbors in the reverse order of receipt.
>
> The next issue in the continue is in the description of execution trace mentioned after the node x actor received Req(2) message from the lossy channel actor then x actor replies lossy actor by sending Busy message. I can't find this event in the Figure 7.5.

In the top rectangle of actor "x" the requests received and sent do not seem to be in the reverse order.
The actor "x"
1 - receives "Req(1)" from "wr"
2 - receives "Req(2)" from "lossy"
3 - receives "Req(2)" from "sdrain"
4 - after processing "Req(1)", it sends "Req(1)" to "sdrain" and to "lossy" (the order here is not relevant - it did not processed Req(2) yet)
5 - after processing "Req(2)", it sends "Req(2)" to "wr" and "Busy" to "lossy".

Note that the diagram only describes sending and receiving, not the messages being processed.
I hope it makes sense to you.

> For last question, Example 6.3.5. in the page 150 is used for showing why the actor of LossySync channel with input port c and output port d is not a proactive actor, so it refers to Figure 6.4 on the left (attached). For the proving, it is shown none of two port are not proactive. This means two ports can not be value independent from all others in an atomic step of a transition, therefor, it is assumed that if we have two value v and w from domain D and are not equal to each other then we have a transition from state q to itself by label l3(v) where the value v flows through the port c and another transition from q to itself with l3(w) where the value w flows through the port d, but we have not a label named l which contains an atomic step such that v flows through c and w flows through d.
>
> For proving in the above I think concentration is on the synchronous behavior of LossySync channel but when LossySync act like a barrier so we use l4(w) for showing proactive nature of LossySync actor based on related definition. Am I correct in this view?

I did not understand your point very well. A proactive actor is, for example, a writer that can send data, or a fifo that can either receive data or send data.
Intuitively, a port is proactive if it is ready to send data or to receive data, and the data does not come from anywhere else nor it goes to anywhere else. I make this more precise using what I call value independence, to explain what it means for the data to not come from anywhere and not to go to anywhere.
Hence, in this view the lossy has no "proactive nature", as you put it. That is, data on each of the ports can depend or influence data on other ports, so they are not value-independent.

Best,
José

--
Jose Proenca
http://people.cs.kuleuven.be/~jose.proenca

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Reply all
Reply to author
Forward
0 new messages