[kepler-dev] Handling shared-resources
pnorbert at cs.ucdavis.edu
Fri Mar 9 11:03:05 PST 2007
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
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
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.
More information about the Kepler-dev