/* * Copyright 2010 OpenSourceStewardshipFoundation * * Licensed under BSD */ #include #include #include "VMS.h" /*The animationMaster embodies most of the animator of the language. The * animator is what emodies the behavior of language constructs. * As such, it is the animationMaster, in combination with the plugin * functions, that make the language constructs do their behavior. * *Within the code, this is the top-level-function of the masterVPs, and * runs when the coreController has no more slave VPs. It's job is to * refill the animation slots with slaves. * *To do this, it scans the animation slots for just-completed slaves. * Each of these has a request in it. So, the master hands each to the * plugin's request handler. *Each request represents a language construct that has been encountered * by the application code in the slave. Passing the request to the * request handler is how that language construct's behavior gets invoked. * The request handler then performs the actions of the construct's * behavior. So, the request handler encodes the behavior of the * language's parallelism constructs, and performs that when the master * hands it a slave containing a request to perform that construct. * *On a shared-memory machine, the behavior of parallelism constructs * equals control, over order of execution of code. Hence, the behavior * of the language constructs performed by the request handler is to * choose the order that slaves get animated, and thereby control the * order that application code in the slaves executes. * *To control order of animation of slaves, the request handler has a * semantic environment that holds data structures used to hold slaves * and choose when they're ready to be animated. * *Once a slave is marked as ready to be animated by the request handler, * it is the second plugin function, the Assigner, which chooses the core * the slave gets assigned to for animation. Hence, the Assigner doesn't * perform any of the semantic behavior of language constructs, rather * it gives the language a chance to improve performance. The performance * of application code is strongly related to communication between * cores. On shared-memory machines, communication is caused during * execution of code, by memory accesses, and how much depends on contents * of caches connected to the core executing the code. So, the placement * of slaves determines the communication caused during execution of the * slave's code. *The point of the Assigner, then, is to use application information during * execution of the program, to make choices about slave placement onto * cores, with the aim to put slaves close to caches containing the data * used by the slave's code. * *========================================================================== *In summary, the animationMaster scans the slots, finds slaves * just-finished, which hold requests, pass those to the request handler, * along with the semantic environment, and the request handler then manages * the structures in the semantic env, which controls the order of * animation of slaves, and so embodies the behavior of the language * constructs. *The animationMaster then rescans the slots, offering each empty one to * the Assigner, along with the semantic environment. The Assigner chooses * among the ready slaves in the semantic Env, finding the one best suited * to be animated by that slot's associated core. * *========================================================================== *Implementation Details: * *There is a separate masterVP for each core, but a single semantic * environment shared by all cores. Each core also has its own scheduling * slots, which are used to communicate slaves between animationMaster and * coreController. There is only one global variable, _VMSMasterEnv, which * holds the semantic env and other things shared by the different * masterVPs. The request handler and Assigner are registered with * the animationMaster by the language's init function, and a pointer to * each is in the _VMSMasterEnv. (There are also some pthread related global * vars, but they're only used during init of VMS). *VMS gains control over the cores by essentially "turning off" the OS's * scheduler, using pthread pin-to-core commands. * *The masterVPs are created during init, with this animationMaster as their * top level function. The masterVPs use the same SlaveVP data structure, * even though they're not slave VPs. *A "seed slave" is also created during init -- this is equivalent to the * "main" function in C, and acts as the entry-point to the VMS-language- * based application. *The masterVPs shared a single system-wide master-lock, so only one * masterVP may be animated at a time. *The core controllers access _VMSMasterEnv to get the masterVP, and when * they start, the slots are all empty, so they run their associated core's * masterVP. The first of those to get the master lock sees the seed slave * in the shared semantic environment, so when it runs the Assigner, that * returns the seed slave, which the animationMaster puts into a scheduling * slot then switches to the core controller. That then switches the core * over to the seed slave, which then proceeds to execute language * constructs to create more slaves, and so on. Each of those constructs * causes the seed slave to suspend, switching over to the core controller, * which eventually switches to the masterVP, which executes the * request handler, which uses VMS primitives to carry out the creation of * new slave VPs, which are marked as ready for the Assigner, and so on.. * *On animation slots, and system behavior: * A request may linger in a animation slot for a long time while * the slaves in the other slots are animated. This only becomes a problem * when such a request is a choke-point in the constraints, and is needed * to free work for *other* cores. To reduce this occurance, the number * of animation slots should be kept low. In balance, having multiple * animation slots amortizes the overhead of switching to the masterVP and * executing the animationMaster code, which drives for more than one. In * practice, the best balance should be discovered by profiling. */ void animationMaster( void *initData, SlaveVP *masterVP ) { //Used while scanning and filling animation slots int32 slotIdx, numSlotsFilled; AnimSlot *currSlot, **animSlots; SlaveVP *assignedSlaveVP; //the slave chosen by the assigner //Local copies, for performance MasterEnv *masterEnv; SlaveAssigner slaveAssigner; RequestHandler requestHandler; void *semanticEnv; int32 thisCoresIdx; //======================== Initializations ======================== masterEnv = (MasterEnv*)_VMSMasterEnv; thisCoresIdx = masterVP->coreAnimatedBy; animSlots = masterEnv->allAnimSlots[thisCoresIdx]; requestHandler = masterEnv->requestHandler; slaveAssigner = masterEnv->slaveAssigner; semanticEnv = masterEnv->semanticEnv; HOLISTIC__Insert_Master_Global_Vars; //======================== animationMaster ======================== while(1){ MEAS__Capture_Pre_Master_Point //Scan the animation slots numSlotsFilled = 0; for( slotIdx = 0; slotIdx < NUM_ANIM_SLOTS; slotIdx++) { currSlot = animSlots[ slotIdx ]; //Check if newly-done slave in slot, which will need request handled if( currSlot->workIsDone ) { currSlot->workIsDone = FALSE; currSlot->needsSlaveAssigned = TRUE; HOLISTIC__Record_AppResponder_start; MEAS__startReqHdlr; //process the requests made by the slave (held inside slave struc) (*requestHandler)( currSlot->slaveAssignedToSlot, semanticEnv ); HOLISTIC__Record_AppResponder_end; MEAS__endReqHdlr; } //If slot empty, hand to Assigner to fill with a slave if( currSlot->needsSlaveAssigned ) { //Call plugin's Assigner to give slot a new slave HOLISTIC__Record_Assigner_start; assignedSlaveVP = (*slaveAssigner)( semanticEnv, currSlot ); //put the chosen slave into slot, and adjust flags and state if( assignedSlaveVP != NULL ) { currSlot->slaveAssignedToSlot = assignedSlaveVP; assignedSlaveVP->animSlotAssignedTo = currSlot; currSlot->needsSlaveAssigned = FALSE; numSlotsFilled += 1; HOLISTIC__Record_Assigner_end; } } } MEAS__Capture_Post_Master_Point; masterSwitchToCoreCtlr( masterVP ); flushRegisters(); DEBUG__printf(FALSE,"came back after switch to core -- so lock released!"); }//while(1) }