This is the base star for a family of stars which supports a mutable system configuration in the DE-domain. This star family implements the functionality of a dynamic map-function for the discrete-event domain. A dynamic map-function works like the map-function in the HOF-domain, but we can change the number of blocks it multiplies during runtime of the simulation. Thus, we support a mutable system configuration. Note, that this star family only works with the two standard DE schedulers.
This class is an abstract class, so it can't be instantiated and can not be used on its own. It contains methods which are used by its childs.
Derived from: DEStar
Location: $PTOLEMY/src/domains/de/contrib/stars
Version: 1.8 "03/27/98"
Author: J. Voigt
Acknowledgements: I use some code from Edward A. Lee's older version of
HOFBase. Former versions of DEDynMapBase called that code
directly. But, Tom Lane changed the HOF-stars. So, I copied the older code
directly into this file, having the advantage of being independent of further
changes in HOF now. MutableCQScheduler incorporated by John S. Davis II
blockname | StringState | The name of the block which 'll be instantiated. | "" |
where_defined | StringState | The full path and facet name for the definition of blockname. | "" |
output_map | StringArrayState | The names of the block's outputs for mapping. | "" |
input_map | StringArrayState | The names of the block's inputs for mapping. | "" |
parameter_map | StringArrayState | The mapping of parameters. | "" |
This star contains methods which are used by DEDynMap and DEDynMapGr for an instantiation of other blocks during runtime of the simulation. The descriptions of these stars explain their application. We here just explain the single methods.
We create blocks using code from HOFBase::createBlock in createBlock. This method returns a pointer to a newly created block. This block is instantiated, gets a unique name, and is added to the galaxy's blocklist. Furthermore, we put it into an internal list, so that we can find it back lateron when we want to delete it.
Then we look for input and output portholes of that newly created block and create approriate farsides for these portholes in DEDynMerge and DEDynFork using their createPortHole()-method. These portholes are connected afterwards. We here just have pure virtual methods connectXXXports, because these portholes can be of different datatypes and are members of our childs only. Once they are connected, the newly created portholes are initialized.
If parameter_map is not empty, the parameters in the new block are set in setParameter. If it is empty, the initialization()-method sets the default values.
The entire galaxy's connectivity is checked. Then we check for delayfreeloops and update the porthole priorities.
We have to take special care of source-stars in the dynamically created blocks. We look for them in scanGalaxyForSources. If there are any, we have to give them an initial event at the current time. That means, all source-stars derived from DERepeat-star give now out an initial event at the time of their creation (instead of time zero, when they probably don't exist). Otherwise these source-stars would never give out any event. See the description of the DERepeat-star for details.
I get a unique identifier for a block to be deleted as parameter. This block is looked for in my internal list of currently existing blocks. I get a pointer to my deleteBlock from this list and remove that block from the list.
Then, the eventqueue is checked for any events pointing to deleteblock using scanEventList. If any events are found, they are deleted from the eventqueue.
Then I look for input and output of the deleteblock. Again, the disconnectXXXPorts are here just pure virtual, because the portholes are members of our childs and of a specila datatype. Inside disconnectXXXPorts we check the eventqueue for any events which are scheduled to the farside of the deleteblock's outputs. These farside are inputs, so events might be sent to them.Since we delete these farside, we better also delete the events. Then I disconnect the portholes from their farside and delete their farside using removePortHole() in DEDynMerge and DEDynFork, respectively.
Next, I remove deleteblock from the galaxy's blocklist, where it was added to by the code from createDynBlock. Once removed there, it can be recycled into our blockpool.
The entire galaxy's connectivity it checked again. Then I check for delayfreeloops again and update the porthole priorities.
Using scanEventList() and scanGalaxyForContents() I go down the block's hierarchy until I only deal with atomic elements (stars). For each star I check the current eventQueue for any pending pointer to it (CQScheduler and MutableCQSCheduler) or for any pending pointer to any of its input-portholes (DEScheduler) using deletePendingEventsOfStar or deletePendingEventsOfPortHole, which should be self-exploratory both.
All parameters are used in the derived class DEDynMap.
A block which is to instantiate must not have multiportholes.
FIXME: The eventlist is to re-sort after the configuration changed. Thanks to Tom Lane for pointing this out.
See: source code,
DynMapBase users
copyright (c) 1997 Dresden University of Technology, WiNeS-Project All rights reserved. See the file $PTOLEMY/copyright for copyright notice, limitation of liability, and disclaimer of warranty provisions.