VMS/VMS_Implementations/VMS_impls/VMS__MC_shared_impl

view AnimationMaster.c @ 256:2bcf37fd50c6

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