# HG changeset patch # User Me # Date 1277000772 25200 # Node ID e2de204909bfbcbdd78f1fa8669dfa31344a4820 # Parent 09ff1aeb5d8d78aa3c70d900d73fe38da9f7a4bd Middle of testing core loop diff -r 09ff1aeb5d8d -r e2de204909bf MasterLoop.c --- a/MasterLoop.c Sat Jun 19 19:25:24 2010 -0700 +++ b/MasterLoop.c Sat Jun 19 19:26:12 2010 -0700 @@ -16,47 +16,42 @@ /*This code is animated by the virtual Master processor. - *Note, it is animated on a different level in virtual processor hierarchy - * than the CoreLoop -- this is the code pointed to in a work-unit that the - * coreLoop jumps to * - *Polls each virtual slave exactly once, hands any requests made by the slave - * to the "request handler" plug-in function + *Polls each sched slot exactly once, hands any requests made by a newly + * done slave to the "request handler" plug-in function * - *Any slaves that have no work-unit assigned are given to the "schedule" - * plug-in function, which tries to assign a work-unit to it. + *Any slots that need a virt procr assigned are given to the "schedule" + * plug-in function, which tries to assign a virt procr (slave) to it. * - *When all slaves that need work-units have been given to the schedule plug-in, - * half of the ones that were successfully scheduled are put into the work - * queue, then a continuation of this function is put in, then the rest of the - * slaves that were successfully scheduled. + *When all slots needing a processor have been given to the schedule plug-in, + * a fraction of the procrs successfully scheduled are put into the + * work queue, then a continuation of this function is put in, then the rest + * of the virt procrs that were successfully scheduled. * - *The first thing this function does is busy-wait until the previous work-unit - * running this function is done. This ensures it doesn't overlap with - * tail-end of previous -- IE, continuation may sneak through queue before - * previous done putting second half of scheduled slaves in. This is the only - * race condition. + *The first thing the continuation does is busy-wait until the previous + * animation completes. This is because an (unlikely) continuation may + * sneak through queue before previous continuation is done putting second + * part of scheduled slaves in, which is the only race condition. * */ /*May 29, 2010 -- birth a Master during init so that first core loop to - * start running gets it and does all the stuff for a newly born - * from then on, will be doing continuation -- but do suspension self + * start running gets it and does all the stuff for a newly born -- + * from then on, will be doing continuation, but do suspension self * directly at end of master loop *So VMS__init just births the master virtual processor same way it births * all the others -- then does any extra setup needed and puts it into the * work queue. *However means have to make masterEnv a global static volatile the same way * did with workQ in core loop. -- for performance, put the - * jump to core loop directly in here, and have it directly jump back. + * jump to the core loop directly in here, and have it directly jump back. */ void masterLoop( void *initData, VirtProcr *masterPr ) - { bool8 success; + { bool8 retCode; int slotIdx, numScheduled, numInFirstChunk, filledSlotIdx; SchedSlot *currSlot, **schedSlots, **filledSlots; MasterEnv *masterEnv; - QueueStruc *workQ; -// VirtProcr *masterPr; + CASQueueStruc *workQ; void *jmpPt; SlaveScheduler slaveScheduler; @@ -73,6 +68,7 @@ //if another reference to same Master VirtProcr still going, busy-wait //Could put this lower, but don't want to think about shared stack.. + masterEnv = _VMSMasterEnv; while( masterEnv->stillRunning ) /*busy wait*/ ; //TODO: want to do busy-wait as assembly, to be sure stack not touched? @@ -82,12 +78,11 @@ //TODO: gdb -- check that a volatile _VMSMasterEnv and _VMSWorkQ means // all these will be re-filled every time jump here.. workQ = _VMSWorkQ; - masterEnv = _VMSMasterEnv; requestHandler = masterEnv->requestHandler; slaveScheduler = masterEnv->slaveScheduler; schedSlots = masterEnv->schedSlots; filledSlots = masterEnv->filledSlots; - masterPr = masterEnv->masterVirtPr; + masterPr = masterEnv->masterVirtPr; //post-jmp clobbered, re-load //prepare for scheduling @@ -108,10 +103,10 @@ } if( currSlot->needsProcrAssigned ) { //give slot a new virt procr - success = + retCode = (*slaveScheduler)( currSlot, masterEnv->semanticEnv ); - if( success ) + if( retCode == 1 ) { int numFilled = masterEnv->numFilled; filledSlots[numFilled] = currSlot; @@ -119,6 +114,12 @@ currSlot->needsProcrAssigned = FALSE; } + else if( retCode == -1 ) //scheduler plug-in says to shut down VMS + { + //shutdown -- make "end Thd" virt-procs whose nextInstrPt is the + // coreloop's EndCoreLoopPt -- causing a jump to the EndThread + // and any other shut-down. + } } } @@ -126,17 +127,17 @@ numInFirstChunk = masterEnv->numFilled / 2; //tweak this from experiments for( filledSlotIdx = 0; filledSlotIdx < numInFirstChunk; filledSlotIdx++) { - writeQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ ); + writeCASQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ ); } //enqueue continuation of this loop // note that After this enqueue, continuation might sneak through - writeQ( schedSlots[0]->procrAssignedToSlot, workQ );//master always slot 0 + writeCASQ( schedSlots[0]->procrAssignedToSlot, workQ );//master always slot 0 for( filledSlotIdx = numInFirstChunk; filledSlotIdx < numScheduled; filledSlotIdx++) { - writeQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ ); + writeCASQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ ); } masterEnv->numFilled = 0;