Mercurial > cgi-bin > hgwebdir.cgi > VMS > VMS_Implementations > VMS_impls > VMS__MC_shared_impl
view AnimationMaster.c @ 234:0ee1a3c8972d
Merged Nina's fix of assembly with Sean's comments and cleanup
| author | Some Random Person <seanhalle@yahoo.com> |
|---|---|
| date | Fri, 16 Mar 2012 10:43:15 -0700 |
| parents | 421bde2a07d7 |
| children | ecbf6992dab4 |
line source
1 /*
2 * Copyright 2010 OpenSourceStewardshipFoundation
3 *
4 * Licensed under BSD
5 */
9 #include <stdio.h>
10 #include <stddef.h>
12 #include "VMS.h"
15 //========================= Local Fn Prototypes =============================
16 void inline
17 stealWorkInto( SchedSlot *currSlot, VMSQueueStruc *readyToAnimateQ,
18 SlaveVP *masterVP );
20 //===========================================================================
24 /*The animationMaster embodies most of the animator of the language. The
25 * animator is what emodies the behavior of language constructs.
26 * As such, it is the animationMaster, in combination with the plugin
27 * functions, that make the language constructs do their behavior.
28 *
29 *Within the code, this is the top-level-function of the masterVPs, and
30 * runs when the coreController has no more slave VPs. It's job is to
31 * refill the animation slots with slaves.
32 *
33 *To do this, it scans the animation slots for just-completed slaves.
34 * Each of these has a request in it. So, the master hands each to the
35 * plugin's request handler.
36 *Each request represents a language construct that has been encountered
37 * by the application code in the slave. Passing the request to the
38 * request handler is how that language construct's behavior gets invoked.
39 * The request handler then performs the actions of the construct's
40 * behavior. So, the request handler encodes the behavior of the
41 * language's parallelism constructs, and performs that when the master
42 * hands it a slave containing a request to perform that construct.
43 *
44 *On a shared-memory machine, the behavior of parallelism constructs
45 * equals control, over order of execution of code. Hence, the behavior
46 * of the language constructs performed by the request handler is to
47 * choose the order that slaves get animated, and thereby control the
48 * order that application code in the slaves executes.
49 *
50 *To control order of animation of slaves, the request handler has a
51 * semantic environment that holds data structures used to hold slaves
52 * and choose when they're ready to be animated.
53 *
54 *Once a slave is marked as ready to be animated by the request handler,
55 * it is the second plugin function, the Assigner, which chooses the core
56 * the slave gets assigned to for animation. Hence, the Assigner doesn't
57 * perform any of the semantic behavior of language constructs, rather
58 * it gives the language a chance to improve performance. The performance
59 * of application code is strongly related to communication between
60 * cores. On shared-memory machines, communication is caused during
61 * execution of code, by memory accesses, and how much depends on contents
62 * of caches connected to the core executing the code. So, the placement
63 * of slaves determines the communication caused during execution of the
64 * slave's code.
65 *The point of the Assigner, then, is to use application information during
66 * execution of the program, to make choices about slave placement onto
67 * cores, with the aim to put slaves close to caches containing the data
68 * used by the slave's code.
69 *
70 *==========================================================================
71 *In summary, the animationMaster scans the slots, finds slaves
72 * just-finished, which hold requests, pass those to the request handler,
73 * along with the semantic environment, and the request handler then manages
74 * the structures in the semantic env, which controls the order of
75 * animation of slaves, and so embodies the behavior of the language
76 * constructs.
77 *The animationMaster then rescans the slots, offering each empty one to
78 * the Assigner, along with the semantic environment. The Assigner chooses
79 * among the ready slaves in the semantic Env, finding the one best suited
80 * to be animated by that slot's associated core.
81 *
82 *==========================================================================
83 *Implementation Details:
84 *
85 *There is a separate masterVP for each core, but a single semantic
86 * environment shared by all cores. Each core also has its own scheduling
87 * slots, which are used to communicate slaves between animationMaster and
88 * coreController. There is only one global variable, _VMSMasterEnv, which
89 * holds the semantic env and other things shared by the different
90 * masterVPs. The request handler and Assigner are registered with
91 * the animationMaster by the language's init function, and a pointer to
92 * each is in the _VMSMasterEnv. (There are also some pthread related global
93 * vars, but they're only used during init of VMS).
94 *VMS gains control over the cores by essentially "turning off" the OS's
95 * scheduler, using pthread pin-to-core commands.
96 *
97 *The masterVPs are created during init, with this animationMaster as their
98 * top level function. The masterVPs use the same SlaveVP data structure,
99 * even though they're not slave VPs.
100 *A "seed slave" is also created during init -- this is equivalent to the
101 * "main" function in C, and acts as the entry-point to the VMS-language-
102 * based application.
103 *The masterVPs shared a single system-wide master-lock, so only one
104 * masterVP may be animated at a time.
105 *The core controllers access _VMSMasterEnv to get the masterVP, and when
106 * they start, the slots are all empty, so they run their associated core's
107 * masterVP. The first of those to get the master lock sees the seed slave
108 * in the shared semantic environment, so when it runs the Assigner, that
109 * returns the seed slave, which the animationMaster puts into a scheduling
110 * slot then switches to the core controller. That then switches the core
111 * over to the seed slave, which then proceeds to execute language
112 * constructs to create more slaves, and so on. Each of those constructs
113 * causes the seed slave to suspend, switching over to the core controller,
114 * which eventually switches to the masterVP, which executes the
115 * request handler, which uses VMS primitives to carry out the creation of
116 * new slave VPs, which are marked as ready for the Assigner, and so on..
117 *
118 *On animation slots, and system behavior:
119 * A request may linger in a animation slot for a long time while
120 * the slaves in the other slots are animated. This only becomes a problem
121 * when such a request is a choke-point in the constraints, and is needed
122 * to free work for *other* cores. To reduce this occurance, the number
123 * of animation slots should be kept low. In balance, having multiple
124 * animation slots amortizes the overhead of switching to the masterVP and
125 * executing the animationMaster code, which drives for more than one. In
126 * practice, the best balance should be discovered by profiling.
127 */
128 void animationMaster( void *initData, SlaveVP *masterVP )
129 {
130 //Used while scanning and filling animation slots
131 int32 slotIdx, numSlotsFilled;
132 SchedSlot *currSlot, **schedSlots;
133 SlaveVP *assignedSlaveVP; //the slave chosen by the assigner
135 //Local copies, for performance
136 MasterEnv *masterEnv;
137 SlaveAssigner slaveAssigner;
138 RequestHandler requestHandler;
139 void *semanticEnv;
140 int32 thisCoresIdx;
142 //======================== Initializations ========================
143 masterEnv = (MasterEnv*)_VMSMasterEnv;
145 thisCoresIdx = masterVP->coreAnimatedBy;
146 schedSlots = masterEnv->allSchedSlots[thisCoresIdx];
148 requestHandler = masterEnv->requestHandler;
149 slaveAssigner = masterEnv->slaveAssigner;
150 semanticEnv = masterEnv->semanticEnv;
153 //======================== animationMaster ========================
154 while(1){
156 MEAS__Capture_Pre_Master_Point
158 //Scan the animation slots
159 numSlotsFilled = 0;
160 for( slotIdx = 0; slotIdx < NUM_SCHED_SLOTS; slotIdx++)
161 {
162 currSlot = schedSlots[ slotIdx ];
164 //Check if newly-done slave in slot, which will need request handld
165 if( currSlot->workIsDone )
166 {
167 currSlot->workIsDone = FALSE;
168 currSlot->needsSlaveAssigned = TRUE;
170 MEAS__startReqHdlr;
172 //process the requests made by the slave (held inside slave struc)
173 (*requestHandler)( currSlot->slaveAssignedToSlot, semanticEnv );
175 MEAS__endReqHdlr;
176 }
177 //If slot empty, hand to Assigner to fill with a slave
178 if( currSlot->needsSlaveAssigned )
179 { //Call plugin's Assigner to give slot a new slave
180 assignedSlaveVP =
181 (*slaveAssigner)( semanticEnv, currSlot );
183 //put the chosen slave into slot, and adjust flags and state
184 if( assignedSlaveVP != NULL )
185 { currSlot->slaveAssignedToSlot = assignedSlaveVP;
186 assignedSlaveVP->schedSlotAssignedTo = currSlot;
187 currSlot->needsSlaveAssigned = FALSE;
188 numSlotsFilled += 1;
189 }
190 }
191 }
193 MEAS__Capture_Post_Master_Point;
195 masterSwitchToCoreCtlr( masterVP );
196 flushRegisters();
197 }//while(1)
198 }