[kepler-dev] Handling shared-resources

Christopher Brooks cxh at eecs.berkeley.edu
Wed Mar 7 09:56:29 PST 2007


Hi Norbert,

Ptolemy has ptolemy/moml/SharedParameter.java

 This parameter is shared throughout a model. Changing the expression of
 any one instance of the parameter will result in all instances that
 are shared being changed to the same expression.  An instance elsewhere
 in the model (within the same top level) is shared if it has the
 same name and its container is of the class specified in the
 constructor (or of the container class, if no class is specified
 in the constructor). Note that two parameters with the same
 expression do not necessarily have the same value, since the
 expression may reference other parameters that are in scope.
 <p>
 One exception is that if this parameter is (deeply) within an
 instance of EntityLibrary, then the parameter is not shared.
 Were this not the case, then opening a library containing this
 parameter would force expansion of all the sublibraries of
 EntityLibrary, which would defeat the lazy instantiation
 of EntityLibrary.
 <p>
 When this parameter is constructed, the specified container
 will be used to infer the parameter value from the container.
 That is, if the container is within a model that has any
 parameters shared with this one, then the value will be
 set to the last of those encountered.
 If the container is subsequently changed, it is up to the
 code implementing the change to use the inferValueFromContext()
 method to reset the value to match the new context.
 Note that this really needs to be done if the container
 of the container, or its container, or any container
 above this parameter is changed.  It is recommended to use
 the four-argument constructor, so you can specify a default
 value to use if there are no shared parameters.
 <p>
 Note that it might be tempting to use a static parameter field
 to achieve this effect, but this would be problematic for two
 reasons. First, the parameter would only be able to have one
 container. Second, the parameter would be shared across all
 models in the same Java virtual machine, not just within a
 single model.

Also, there is ptolemy/actor/lib/Publisher.java
ptolemy/actor/lib/Subscriber.java
ptolemy/actor/lib/SubscriptionAggregator.java

_Christopher
--------

    Hi,
    
    Does anyone handle a "resource" in a workflow "shared" among actors?
    
    I mean like org.kepler.actor.Logger that opens a file once but many 
    instances of that actor in the workflow can write into the same file. So 
    there is no need to drag channels from many actors to one single Logger 
    actor. The file is then (supposed to be) closed at the end of the workflow 
    execution once.
    
    Or, the org.kepler.actor.ssh.* actors that share an established ssh 
    session to perform remote operations. The session should be closed at the 
    very end of the execution.
    
    I have learnt from the recent thread "Wrapup sequence question" that I was 
    wrong about that actors can be aware of the finalization stage of the 
    model/workflow, I have put the finalization of shared resources into the 
    wrapup() method. However, under PN, individual actors can wrap-up 
    surprisingly early, even before another actors start working.
    
    My question is to those who handle shared resources: When and how do you 
    close/finalize them?
    
    I am not sure that actor-oriented modelling allows shared resources at 
    all, or they are just examples of violating it.
    
    Best regards
    Norbert
    
    
          Norbert Podhorszki
        ------------------------------------
          University of California, Davis
          Department of Computer Science
          1 Shields Ave, 2236 Kemper Hall
          Davis, CA 95616
          (530) 752-5076
          pnorbert at cs.ucdavis.edu
          ----------------------------------
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------


More information about the Kepler-dev mailing list