[kepler-dev] Re: Possible race condition

[xiaowen]

Hi,


I think I see the error in my thinking.

I use a diamond to connect two paths of execution before sending it to a
composite actor and use another diamond inside the composite actor to
split it.  So that's equivalent to having all four paths meeting in one
diamond, like:

A --> ** --> C
B --> ** --> D

I send one token (x) to A, then retrieve (x) from C before sending
another token (y) to B.  So I expected that I would receive the tokens
in that order (x, y) at D as well.  However, every few hundred or few
thousand iterations (when the composite actor was created from an
external XML file), I received the tokens in the order (y, x) at D.  I
think it's because A sends (x) to C, then its thread gets interrupted.
Then B sends (y) to C and D.  Finally, A wakes up to send (x) to D.

The solution is to put a no op actor in between like:

A --> *                     * --> C
B --> * --> No Op actor --> * --> D


Thanks for reading!
Xiaowen


Am Donnerstag, den 16.12.2004, 11:53 -0800 schrieb xiaowen:
> Hi Everyone,
> 
> 
> I'm seeing a possible race condition in a PN workflow where tokens are
> not generated in the desired order.  Knowing PN does not guarantee the
> order of tokens, I've tried putting a synchronizer component in to force
> the order. This component seems to work when it's part of a composite
> actor, but not when it's specified in a separate MoML file.  I've
> attached four files to reproduce the situation.
> 
> 
> $ ls
> racecondition-composite.xml  RaceCondition.java  racecondition.xml  Synchronizer.xml
> 
> $ javac -classpath $PTII:$PTII/ptolemy/ptsupport.jar:$PTII/ptolemy/ptolemy.jar RaceCondition.java
> 
> $ java -classpath $PTII:$PTII/ptolemy/ptsupport.jar:$PTII/ptolemy/ptolemy.jar:$PTII/ptolemy/domains/domains.jar:. RaceCondition racecondition.xml
> <Wait up to maybe ten thousand iterations.>
> <Workflow gives wrong answer.>
> 
> $ java -classpath $PTII/ptolemy/ptsupport.jar:$PTII/ptolemy/domains/domains.jar:. RaceCondition racecondition-composite.xml
> <Wait forever>
> <No errors until Java runs out of memory.>
> 
> 
> The Java class runs the workflow specified by the first argument in an
> infinite loop until the workflow outputs the wrong result.
> 
> racecondition.xml and racecondition-composite.xml are identical, except
> for where the synchronizer component is implemented.  The goal of the
> synchronizer component is to remove race conditions by ensuring that
> actors do not receive an input token until they've sent the output token
> corresponding to the previous input.  In racecondition.xml, the
> synchronizer component is placed in a separate MoML file, whereas in
> racecondition-composite.xml, the synchronizer component is copied and
> pasted into a composite actor.
> 
> Because I have a tendency to create very large workflows with dozens and
> dozens of actors, I find the ability to put portions into separate files
> very useful. The time it takes to debug seems to grow exponentially with
> the number of actors in the workflow.  If I can modularize it, then I
> can easily test each portion separately inside junit or a similar
> automated testing framework.
> 
> Will someone please explain to me why the workflow functions flawlessly
> in racecondition-composite.xml, but seems to generate the wrong result
> in racecondition.xml?  Have I created Synchronizer.xml wrong?
> 
> 
> I'm using Ptolemy 4.0.1.
> 
> Thanks in advance!
> Xiaowen
>