1 / 14

Implementing Quantity Managers in Ptolemy II

Implementing Quantity Managers in Ptolemy II. EE 290N Project Haibo Zeng ( zenghb@eecs ) Dec 10 th , 2004. Quantity Managers in Metropolis. Metropolis suggests actors (processes) to be active, each of them has its own thread of control

pearl
Download Presentation

Implementing Quantity Managers in Ptolemy II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing Quantity Managers in Ptolemy II EE 290N Project Haibo Zeng (zenghb@eecs) Dec 10th, 2004

  2. Quantity Managers in Metropolis • Metropolis suggests actors (processes) to be active, each of them has its own thread of control • The execution of the network is described as a sequence of state transitions. In every state there is a set of enabled events. • Events can be annotated with quantities, e.g • Time, power, composite quantities • Concurrent events can be coordinated in terms of quantities • Users have the freedom to define the coordination and specify the algorithms to implement them

  3. Operational Semantics of Metropolis Network • The 2 steps of network execution sequence • Quantity requests • Find all the quantity constraints on every event e • In meta-model, done by Quantity.request(event, requested quantities); • Example: GTime.request(BEG(thisthread, this.cpuRead), t); • Quantity resolution • Find a set of candidate events and quantities annotated with each of the events, such that • All the axioms of the quantity types are satisfied • In Metropolis Meta-model, done by • letting each quantity type implement a resolve() method • iteratively call the resolve() methods of relevantquantity types

  4. Scoreboard Manager … … … … P0 P0 P0 P0 … … P1 P1 P1 P1 … … c0 c0 QM c0 QM QM c0 i1 i1+1 i2 i2+1 i3 Deltacycle Simulating Metropolis Meta-Model P0 • Alternating running phases • Quantity request (all processes run to a named event, update scoreboard) • Quantity resolution ( Quantity Managers do scheduling and quantity annotation) c0 M P1 Thanks to Guang Yang

  5. … … … … P0 P0 P0 P1 P1 P1 Mgr c0 c0 Mgr c0 i1 i2 i1 i2 i3 Deltac Simulating Metropolis Meta-Model Quantity Request Quantity Resolution do{ beg{ port2SM.request( beg_event , NOW); } switch to Quantity Resolution phase wait }while(request is not granted) Y.write(z); do{ end{ begTime=port2SM.A(beg_event); port2SM.request(end(end_event , begTime+4)); } switch to Quantity Resolution phase wait }while(request is not granted) loop{ wait do { call resolve of quantity managers } while (all quantity managers are stable) switch to Quantity Request phase } Thanks to Guang Yang

  6. AspectJ & ADJT • AspectJ • A compatible extension to Java • Adds constructs that enable the modular implementation of concerns cutting across the natural units of modularity (class/object in Java) • ADJT • Plug-ins providing support for AspectJ within the Eclipse IDE

  7. Metropolis vs. AspectJ • Actions • Each statement in the program can be an action • Syntax: <object>.<name> • <object>: process/medium • <name>: label/function defined in <object> • “the execution of the expression at line 37 in file Foo.java” can be defined as an action! • Explicit definition of actions in the process/medium • Joint points • well-defined points in the execution of a program • reading or writing a field • calling or executing an exception handler, method or constructor • And more… • “the execution of the expression at line 37 in file Foo.java” is not a joint point • join points are described by the pointcut declaration. Pointcut can be defined in other classes or aspects, can be named or anonymous

  8. Metropolis vs. AspectJ • Events • BEG(<process>,<action>): the start of the action <action> for a specific process <process> • END(<process>,<action>): the end of the action <action> for a specific process <process> • Three fields: • Type: BEG, END • <process>: which thread of control is this event associated with • <action> • Explicit request-making codes within the block of events • Advices • Code that executes at each joint point • Before advice: runs before the joint point executes • After advice: runs after the joint point • Example: after(): execute(* fire(..)) { i++; } • Advice is defined in aspect outside the class the joint point is in, but it is able to access values in the execution context of a joint point

  9. Quantity Manager vs. Director • Similarity: Both can control the execution order of the actors and mediates their communication. • Differences: Metropolis General purpose event annotation/coordination Allow multiple quantity managers in the same hierarchical level. Cooperation of quantity managers are done through the current set of enabled events. Ptolemy Specific to a certain MoC Hierarchical heterogeneity: each level of interconnected actors to be locally homogeneous, while allowing different models of computation to be specified at different levels in the hierarchy.

  10. Implementing Quantity Managers in Ptolemy II Keep the interface and implementation of each quantity manager the same as in Metropolis public interface QuantityManager { public void request(event e, RequestClass rc); public void resolve(); public void postcond(); public boolean isStable(); } Have an AspectJ program do the rest of the work Mimic the event naming and associated request-making codes by Pointcuts and Advices Record and update the state of each actors Alternate between quantity request/resolution phases Don’t need to touch any Ptolemy code!

  11. Two faces of the life • Good • Property from Ptolemy • Domain-polymorphism actors • Property from Metropolis • Have the freedom to allow multiple quantity managers in the same hierarchical level • Bad • But remember that quantity managers can disable events, thus stalling the thread • It’s not always possible or safe in Ptolemy • Not all domains are thread-oriented • Thread-oriented domains: PN, CSP, DDE • Non-threaded domains: CT, DE, SDF • Others: FSM, Giotto • Not all valid joint points are safe for actors to be stalled

  12. Constraints… • Limited to thread-oriented domains • Limited to larger granulated joint-points • From lecture • Joint-points for all domains: between iterations • Before prefire() • After postfire() • Pure annotating Quantity Managers are not constrained to these limitations

  13. Examples • Power Consumption • PN->SDF • Stall the actors before prefire() • Each time an actor finishes its iteration, get the next actor in the execution queue and notify it • Utilize the kernel in SDF domain in Ptolemy • SDFUtilities • SDFScheduler • …

  14. Conclusion and future work • Done • Perfect usage of pure quantity annotation • Power/Energy… • Limited usage of other type of quantity managers • Limited to thread-oriented domains • PN, CSP, DDE • Limited to larger granulated joint-points • Todo • Possibility of extension to other domains • Understand more about the integration of quantity managers and directors

More Related