knowledge-database (beta)

Possible race condition

xiaowen

From:	xiaowen
Subject:	Possible race condition
Date:	Thu, 16 Dec 2004 11:53:30 -0800

--=-YF3MiKkE4OBKmqBUimg+
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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

$ java -classpath $PTII/ptolemy/ptsupport.jar:$PTII/ptolemy/domains/domains.jar:. RaceCondition racecondition-composite.xml

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

--=-YF3MiKkE4OBKmqBUimg+
Content-Disposition: attachment; filename=racecondition-composite.xml
Content-Type: text/xml; name=racecondition-composite.xml; charset=UTF-8
Content-Transfer-Encoding: 7bit

"http://ptolemy.eecs.berkeley.edu/xml/dtd/MoML_1.dtd">

Create a sequence of tokens with increasing value

Write the value of a string token, one per line, to a text file.

--=-YF3MiKkE4OBKmqBUimg+
Content-Disposition: attachment; filename=RaceCondition.java
Content-Type: text/x-java; name=RaceCondition.java; charset=UTF-8
Content-Transfer-Encoding: 7bit

import java.io.ByteArrayOutputStream;
import java.io.OutputStream;
import java.io.PrintStream;

import ptolemy.actor.gui.MoMLSimpleApplication;

/**
* @author xin2
*/
public class RaceCondition {

public static void main(String[] args) throws Exception {
String strWorkflow;
if(args.length < 1) {
strWorkflow = "racecondition.xml";
} else {
strWorkflow = args[0];
}

System.out.println("Using workflow: " + strWorkflow);

// Reassign stdout.
ByteArrayOutputStream os = new ByteArrayOutputStream();
System.setOut(new PrintStream(os));
for(int i = 0; ; i++) {
System.err.println("Iteration: " + i);
os.reset();
MoMLSimpleApplication app = new MoMLSimpleApplication(strWorkflow);
if(!os.toString().startsWith("one")) {
System.err.println("FAILED. Received:");
System.err.println(os.toString());
System.exit(1);
}
}
}
}

--=-YF3MiKkE4OBKmqBUimg+
Content-Disposition: attachment; filename=racecondition.xml
Content-Type: text/xml; name=racecondition.xml; charset=UTF-8
Content-Transfer-Encoding: 7bit

"http://ptolemy.eecs.berkeley.edu/xml/dtd/MoML_1.dtd">

Create a sequence of tokens with increasing value

Write the value of a string token, one per line, to a text file.

--=-YF3MiKkE4OBKmqBUimg+
Content-Disposition: attachment; filename=Synchronizer.xml
Content-Type: text/xml; name=Synchronizer.xml; charset=UTF-8
Content-Transfer-Encoding: 7bit

"http://ptolemy.eecs.berkeley.edu/xml/dtd/MoML_1.dtd">

--=-YF3MiKkE4OBKmqBUimg+--

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu

From:	xiaowen
Subject:	Re: Possible race condition
Date:	Mon, 20 Dec 2004 09:32:39 -0800

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
>
>
>
> $ java -classpath $PTII/ptolemy/ptsupport.jar:$PTII/ptolemy/domains/domains.jar:. RaceCondition racecondition-composite.xml
>
>
>
>
> 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
>

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu