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

[Colin Enticott]

Hi,

Looking into this further (sorry for the delay, I’ve been busy), it 
looks like all actions on port types obtain a read lock on the 
workspace. When the manager resolves types, it also obtains a read lock, 
but makes changes to the port types. Shouldn't it obtain a write lock?

Thanks,
Colin

Colin Enticott wrote:
>
> 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 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>   


-- 
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/20091009/dc2b44a7/attachment.html>