How to calculate Reo connector time delay with Action Constraint Automata
Alireza Farhadi
Alireza Farhadi
Natallia Kokash
Action constraint automata allow us to avoid unnecessary synchronization when several synchronous regions start to fire data simultaneously but their total delay to transfer data may differ (first example), and also show data transfer through the synchronous region (second example). Since ACA better preserves the information about the network structure than CA, the QoS calculations based on ACA may be more accurate. The question here what exactly you are trying to compute. The total delay makes sense only for one synchronous region or one particular run while the ACA will show you all possible executions of the network. If you want to compute a total delay for any run, you will have to consider rates with which services provide and consume data. This is similar to work by Joung-Joo Moon and Sun Meng on stochastic Reo, but I am not sure the extension is straightforward. Timed constraint automata do not account for delays in synchronous channels, they represent semantics of timed channels where time delay is a functional characteristic of a channel (e.g., a buffered channel deliberately delays output for t time units, etc.) We indeed want to define timed ACA or something like this, but before we do so, we have to define a distributed Reo execution protocol which accounts for time delays in synchronous channels in order to compute so called coordination delay, or delay to decide which transition to fire. If you are interested in this topic, I can share some ideas.
Regards,
Natallia
----- Original Message -----
From: "Alireza Farhadi" <alireza...@gmail.com>
To: reo...@googlegroups.com
Sent: Monday, March 12, 2012 2:47:29 PM
Subject: [reo-dev] Re: How to calculate Reo connector time delay with Action Constraint Automata
Dear Member, (Specially Dr Natallia Kokash and Behnaz Changizi)
In continue to below subject. I think for calculation of data transfer
delay along a Reo connector, we can use same idea mentioned in Timed
Constraint Automata with timer invariant for states and consequently it
could be Timed Action Constraint Automata which be used for proper
estimation of time delay and improve solutions for synchronization of
independent concurrent transaction problem. As a third question in this
subject: Is that assumption to declare TACA, correct?
Regards,
Alireza Farhadi
On Sat, Mar 10, 2012 at 4:56 PM, Alireza Farhadi
<alireza...@gmail.com>wrote:
> Dear Member,
>
> I recently read another Dr. Natallia Kokash et al. paper "A Semantic
> Model for Service Composition with Coordination Time Delays<http://homepages.cwi.nl/~kokash/documents/ICFEM.pdf>"
> they mentioned two weakness for other Reo's semantics (e.g. QCA):
>
> 1- It can not calculate precisely data transformation delays over
> synchronous regions. For example for barrier synchronization connector that
> explained in this paper, the calculated delay equals to maximum of all 5
> contained Sync channel delays (max(t1; t2; t3; t4; t5)) but exact value
> must be (max(t1 +max(t2; t3); t4 +max(t3; t5))).
>
> 2- Another drawback is only one transition on constraint automata can be
> enabled at same time. This condition causes synchronization of independent
> concurrent transactions to be happen.
>
> At first how proposed semantic (ACA) help us to calculate delay time
> properly (I guess there is no indication for finer calculation in this
> papaer) and other question is, when we distinguish a phase named "bolck"
> for a port although we have same problem during block action that we can
> not select any other action in other independent regions and we only reduce
> time for this nonavailability. (I guess with 4 action "block", "start",
> "finish", "unblock" we have only imitated time sharing concepts that
> mimics concurrency on the single processor, Is that correct?)
>
> 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.