[kepler-dev] Thread safety with Ptolemy’s TypedIOPort

[Colin Enticott]

Hi,


First of all, I didn’t think that multiple threads would use the same 
TypedIOPort object, but here’s the story:

I’ve been developing a new "threading director" for Ptolemy, the 
Nimrod/k TDA director[1], and one in every 100 executions of my rigorous 
director threading test workflows, I get an exception. This exception 
happens when an actor sends a token out a TypedIOPort:

(Sorry. The exception is from kepler-1.0.0, so the line numbers differ 
from the current version, but the functions in question are identical)

ptolemy.kernel.util.IllegalActionException: Run-time type checking 
failed. Token 3 with type int is incompatible with port type: int

in .Composite.Ramp.output

at ptolemy.actor.TypedIOPort._checkType(TypedIOPort.java:750)

at ptolemy.actor.TypedIOPort.send(TypedIOPort.java:472)

at ptolemy.actor.lib.Ramp.fire(Ramp.java:138)

at 
org.monash.nimrod.NimrodDirector.NimrodProcessThread.run(NimrodProcessThread.java:347)

The confusing error message is “Token 3 with type int is incompatible 
with port type: int”. Looking into this deeper I believe the error 
message is being generated after the port state has changed.

The function in question is:

protected void _checkType(Token token) throws IllegalActionException {

int compare = TypeLattice.compare(token.getType(), _resolvedType);

if ((compare == CPO.HIGHER) || (compare == CPO.INCOMPARABLE)) {

throw new IllegalActionException(this,

"Run-time type checking failed. Token " + token

+ " with type " + token.getType()

+ " is incompatible with port type: "

+ getType().toString());

}

}

I suspect the “compare” method is called before the type is set (or 
changed) and the error message is generated after the type is set. 
Looking for another thread that could be accessing the TypedIOPort, I 
discovered the type checking functionality. Listening to the manager, it 
looks like the manager is "resolving types" in response to a 
“ChangeRequest”.

Two questions:

Should I use “change requests” in this way? None of the changes will 
cause any problems with types and so I could directly modify the 
workflow. (I initially used change requests as the main thread holds a 
read lock on the workspace when the "manager" fires the “director”)

And, it looks like TypedIOPort is not thread safe. Does this need to be 
fixed? Or should type resolving be completely blocked in a threaded 
environment? The documentation suggests it should be left to the 
director to decide “when it is safe to perform change requests”, but I 
cannot see a way of preventing an actor from doing a type check when 
sending tokens in a threaded environment.


Also, I don't think it is just with my director. It looks like this 
issue will arise in the PN environment, if the workflow makes changes to 
the workflow.

Thanks,

Colin


[1] Abramson D, Enticott C, Altintas I., "Nimrod/K: Towards Massively 
Parallel Dynamic Grid Workflows", IEEE SuperComputing 2008, Austin, 
Texas November 2008


-- 
Colin Enticott, Research Scientist, Ph: +61 03 9903 2215
Room H7.26, Level 7, Building H, Monash University Caulfield 3145, Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20090423/f5979d3a/attachment-0001.html>