priority merger
Bat Pul
I have a need to use a priority merger in a Reo connector.
The priority merger is described in the paper
"Connector colouring I: Synchronisation and context dependency".
In Eclipse I only see a PrioritySync. Is this related?
Can i use a PrioritySync to construct a Priority Merger?
Such that I can use it with animations and mCRL2.
Thanks for any help!
Bat
Christian Krause
welcome to the reo-dev group. You can model a priority merger in ECT as
a component:
1) Create a component and name it, e.g. PMerger
2) Add two source ends "in1" and "in2", and one sink end "out".
3) Select the component in the editor and open the "Properties" view and
select the tab "Animation".
4) Enter the following animation spec here:
table {
out:--- in1:--- in2:->- receive(in1) destroy(in1) create(out)
send(out) next=table;
out:--- in1:-<- in2:--- receive(in2) destroy(in2) create(out)
send(out) next=table;
out:->- in1:-<- in2:-<- next=table;
out:-<- in1:->- in2:->- next=table;
}
Notice the difference between the treatments of in1 and in2 in line 1
and 2. This should correspond to the animation table of the priority
merger in the colouring paper. You can use this component now in your
connectors. I attached an example that shows the priority of in1 -- in
the first step of the animation it will always choose in1 over in2.
Cheers,
Christian
Bat Pul
If i create the priority merger as per the 4 given steps
then Eclipse doesn't allow me to link to it with Sync channels.
The same for other type of channels.
The mouse remain a circle with diagonal (no entrance sign)
when hovering over the in1, in2 and out ends.
Christian Krause
you must use 'links' for that, not Syncs (see also the reo file I
attached in the previous mail).
Cheers,
Christian
Bat Pul
Using links helps! :-)
Now there is a new problem with Java code generation.
If i compose the PriorityMerger outside of the connector
then code can be generated for the connector, but
no Java code is generated for the PriorityMerger.
I get an error for Main:
"priomerg cannot be resolved to a type"
which is correct since no such code is imported, included
or generated.
If i compose the PriorityMerger inside of the connector
then the Java code generator aborts with the empty message:
"org.eclipse.core.runtime.CoreException:"
BTW, do you perhaps know the meaning of the PrioritySync channel?
I couldn't find documentation for it.
Cheers,
bat
Christian Krause
please read on...
On 08/25/11 17:06, Bat Pul wrote:
> Hi Christian,
>
> Using links helps! :-)
>
> Now there is a new problem with Java code generation.
> If i compose the PriorityMerger outside of the connector
> then code can be generated for the connector, but
> no Java code is generated for the PriorityMerger.
> I get an error for Main:
> "priomerg cannot be resolved to a type"
> which is correct since no such code is imported, included
> or generated.
> If i compose the PriorityMerger inside of the connector
> then the Java code generator aborts with the empty message:
> "org.eclipse.core.runtime.CoreException:"
The code generation is based on the constraint automata semantics. Thus,
the animation spec does not help you for that. You should be able to
specify a CA semantics for your component though -- somewhere in the
Properties view. I am not sure whether you need to create a separate
*.ea file for that and point to it, or whether you can do it inline, as
for the animation specs. I have to look into that.
By the way: if you want to generate code for the priority merger you
have a problem: it requires context-dependency, which in the basic CA
encoding is not supported. In principle, it is possible to encode it,
but in the current version it is not supported.
You may also look at the distributed implmentation of Reo developed by
Jose Proenca, as it can be used together with the coloring semantics.
> BTW, do you perhaps know the meaning of the PrioritySync channel?
> I couldn't find documentation for it.
>
No. I think Behnaz Changizi added it at some point. Maybe you can ask
her about it.
Cheers,
Christian
> Cheers,
> bat
>
Alireza Farhadi
At first, thanks a lots for your kinds about guiding us interactively,
Can you explain why PMerger is context dependent and what this means.
Second my question is why constraint automata cannot support context
dependency, excuse me for general question please clarify me.
Regards,
Alireza Farhadi
Christian Krause
a connector or a channel is context-dependent if it behavior depends on
the availability of I/O requests at its ports. The classical example for
this is the LossySync channel. It behaves like a Sync, except that it
loses the incoming data item if the receiving end is not ready to accept
data, i.e., if it did not submit a read-request at the sink end.
In the basic CA encoding, the LossySync behaves nondeterministically.
That means that it may even lose the data item if the receiving part is
ready to accept data. Therefore, the CA encoding of Reo, as presented in
the original paper (http://projects.cwi.nl/credo/Data/SCPJournal04.pdf)
does not support context-dependency.
This issue was solved using a different semantic model for Reo called
the coloring semantics (http://dl.acm.org/citation.cfm?id=1266198) by
using 3 colors (1 for flow and 2 for no-flow), which essentially allows
the channels to distinguish between presence and absence of I/O requests.
To make the story complete, there exists a rather recent result that
basically shows that the coloring semantics (3 colors) can be encoded
into CA (2 colors). This was shown here:
http://www.springerlink.com/content/8225k5j7257656p0/ So, the
constraint automata model is actually expressive enough to encode
context-dependency and this encoding is even compositional.
Now regarding ECT. The animations are based on the coloring semantics.
Thus they support context-dependency but no data. The code generation is
based on the constraint automata semantics from the original paper from
2004. Thus it does NOT support context-dependency, but only data.
I can imagine that this is somewhat confusing, but if you want to
understand the details of the context-dependency problem in Reo, I
recommend that you read the connector coloring paper, and maybe the 2011
paper about how to encode 3 colors into 2 (it is quite intuitive).
From my experience, I recommend you to really think about your specific
application and whether you really need context-dependency and why.
Often context-dependency is used only for convenience and not out of
necessity. There are also cases where context-dependency is actually
harmful (because it enforces "maximal concurrency").
Cheers,
Christian
--
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
Behnaz Changizi
Currently there is no tool support for priority in ECT. However, if you are familiar with mCRL2, you can manually alter the generated specification to eliminate the lower priority. To support priority, we need to model context first. Priority and context will be supported by ECT in upcoming versions.
Good luck,
Behnaz
> 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.
>
>