[kepler-dev] PN + DDF

[Norbert Podhorszki]

Hi Edward,

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.

Best regards
Norbert

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...
>
> Edward
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DDFtest3.xml
Type: text/xml
Size: 10278 bytes
Desc: 
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20060824/3e4208e8/DDFtest3.xml