[kepler-dev] PN + DDF
pnorbert at cs.ucdavis.edu
Thu Aug 24 12:05:30 PDT 2006
Thanks for the fix. It works now in my workflow, where a PN of 25
actors/threads are replaced by one DDF thread. And this is a class,
instantiated 5 times. I like to spare on resources...
It may or may not be worth to mention, that the DDF director works
correctly in my wf only if its parameter 'runUntilDeadlockInOneIteration'
is set (unset by default).
Attached is a bit more complex version of the example I had sent earlier.
The subwf has a branch. If the above parameter is not set, we
receive output tokens for exactly the first half of the input tokens. With
the parameter set, all tokens are produced.
Listening to the DDF Director during execution reveals that the
expressions are fired in one iteration and than the last boolean switch is
fired only in the next iteration (and thus emitting a token every two
iterations). I.e., an iteration is not a full iteration of the DDF subwf
in the first case.
I have to mention too, that if the DDF wubworkflow contains a
BooleanSelect, then it does not work. I should have replaced them with
DDFBooleanSelect, for which there may be a good reason, just I am not
aware of it.
On Wed, 23 Aug 2006, Edward A. Lee wrote:
> Very interesting...
> I'm checking in a fix, and cc'd the author of DDFDirector, so he
> can check whether he agrees with the fix. I've also added your example
> to the test suite. Thanks for providing it.
> The problem was subtle. It turns out that when DDF is inside
> some other domain, and no consumption rates are specified on input
> ports, then it would transfer all available input tokens before
> firing any actors inside. However, if the outside is PN, then input
> tokens are _always_ available (hasToken() always returns true
> at an input port). Hence, the DDFDirector was stuck in an infinite
> loop transferring input tokens.
> My change to DDFDirector is simple. The transferInputs() methods
> transfers at most one token if no rates are specified. Notice that
> this is the right behavior also if the outside domain is SDF!
> The previous behavior would result in non-sdf behavior even
> if the inside DDF composite semantically exhibited SDF behavior
> at its boundaries. So I'm pretty sure this is the semantics we want...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10278 bytes
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20060824/3e4208e8/DDFtest3.xml
More information about the Kepler-dev