[kepler-dev] Handling shared-resources

[Norbert Podhorszki]

Hi Edward and Christopher,

Thanks for the comments and suggestions on this topic.

I realize that I am actually talking about tasks that are somewhat
'external' to the Ptolemy/Kepler environment and thus the actor-oriented 
modelling.

When logging to a file to make a trace what the workflow is doing, this is 
actually not part of the modelling of the original problem. It is simply 
an additional engineering task to be done. When executing remote commands 
through ssh, opening and closing a session should not be part of modelling 
of workflows similarly as inode handling is not part of file management in 
C programs. This things can/should be hidden from the workflow builder.

Passing a token around is a good idea if the shared resource is (an 
important) part of the modelled world, and exclusive access to it should 
be ensured. In case of logging, however, the order of logs are not 
important and non-mixing of lines is ensured by a synchronized method 
within the logger actor. In case of ssh connections, the concurrent access 
to them is essential, moreover the actors are usually parametrized by the 
reference to the connection, and work concurrently under PN (and 
practically use the connection all the time repeatedly).
Nevertheless, in case of the job package, the job (object token) should 
only be passed in tokens around and JobStatus should not be fired 
after/with JobRemover e.g. Here, the shared resource is part of the 
modelling.

I think at this moment that I have to take the handling of closing such 
resources from the actor realm and put deeper into special classes (like 
the ssh package handles everything about remote operations and the actors 
just use them like java.io). That package and the logger could also use a 
special class that subscribes to the workflow director to get notified 
when the execution finishes and do the finalization silently.

You see, we are approching the question with different preferences. I am 
not so interested in the correct modelling of the problem then in 
providing a simple (one actor max, or hidden) solution for workflow builders.
Using rendezvous domain just for ensuring logging is not feasible in 
Kepler practice when we use PN for pipelining and DDF/SDF for efficiency.

Besides that, modelling of shared resources is an interesting 
problem for Ptolemy.

Best regards
Norbert