|
|
 | | From: | Christopher Brooks | | Subject: | Re: Possible process domain bug | | Date: | Thu, 16 Dec 2004 08:30:19 -0800 |
|
|
 | I modified BranchController so that if it gets a ClassCastException,
the exception it throws mentions that process domains may not work
inside non-process domains.
I also added a test in pn/test/PNDirector.tcl that runs PNInsideDE.xml
and expects the ClassCastException.
What we really need is a set of simple tests that tries the different
combinations of domains inside each other. Not all combinations work,
we need to better document what combinations do work.
_Christopher
--------
Hi Prof. Lee, all,
> Yes, it looks as if the code is designed so that process domains
> (PN, CSP) can only be used within process domains. I'm not sure
> to what extent this is a limitation of the process domains vs. a
> semantic problem. What would PN mean within DE? Since PN has
> no well-defined notion of a "firing", how would you assign time
> stamps to the outputs of a PN actor? By default in DE, the time
> stamps of the outputs of an actor match those of the inputs that
> triggered the firing. There is no such notion in PN.
Yes, I agree with you, not all combinations are meaningful. As a
matter of fact,
I was combining CSP inside a SR topology. That does not seem right
because of the synchronous
hypothesis. But, I was testing a tool for checking the validity of
specifications against certain MoCs,
and in principle, that combination (SR + CSP) was ok (the specification
isn't timed, is monotonic, etc).
As for DE + CSP I think it might be useful, since DE is primary a
simulation model, as is
CT. Therefore, these two models are pretty good for capturing the
environment of a system. In my
particular case, I'm also interested in embedded software, so CSP an PN
should be put in the mix.
Indeed, trying to view a "process composite actor" as a
"activation based atomic actor" is tricky.
The "fire until deadlock" policy for the process composite seems the way
to go. If no actor inside
the composite manipulates the time value, i.e the composite is zero
delay, then the timestamps of produced
events could be of current time of firing. Now for generating embedded
software, I think it does not make
much sense the notion of timestamp of an event, since the real time is
not a controllable feature. Maybe the only
acceptable method of a process that manipulates time is a timed delay (
fireAt() ) . In a
DE + process this can be interpreted as the generation of a pure event
that will trigger a
future activation of the process based composite. Anyway, issues of
deadlocks, livelocks and
determinacy should be studied carefully.
Regards,
Ivan
P.S.: By April/May of 2005 I should get my PhD, and be a free man. So,
if anyone out there
is interested in a 6 year experienced Ptolemy II guy to develop MoC
science, just let me know ... :-)
---------------------------------------------------------------------------
-
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu
|
|
|
