[kepler-dev] Re: Possible race condition
xin2 at llnl.gov
Mon Dec 20 09:32:39 PST 2004
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
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!
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!
More information about the Kepler-dev