1.1 --- a/MasterLoop.c	Sat Jun 19 19:25:24 2010 -0700
     1.2 +++ b/MasterLoop.c	Sat Jun 19 19:26:12 2010 -0700
     1.3 @@ -16,47 +16,42 @@
     1.4  
     1.5  
     1.6  /*This code is animated by the virtual Master processor.
     1.7 - *Note, it is animated on a different level in virtual processor hierarchy
     1.8 - * than the CoreLoop -- this is the code pointed to in a work-unit that the
     1.9 - * coreLoop jumps to
    1.10   *
    1.11 - *Polls each virtual slave exactly once, hands any requests made by the slave
    1.12 - * to the "request handler" plug-in function
    1.13 + *Polls each sched slot exactly once, hands any requests made by a newly
    1.14 + * done slave to the "request handler" plug-in function
    1.15   *
    1.16 - *Any slaves that have no work-unit assigned are given to the "schedule"
    1.17 - * plug-in function, which tries to assign a work-unit to it.
    1.18 + *Any slots that need a virt procr assigned are given to the "schedule"
    1.19 + * plug-in function, which tries to assign a virt procr (slave) to it.
    1.20   *
    1.21 - *When all slaves that need work-units have been given to the schedule plug-in,
    1.22 - * half of the ones that were successfully scheduled are put into the work
    1.23 - * queue, then a continuation of this function is put in, then the rest of the
    1.24 - * slaves that were successfully scheduled.
    1.25 + *When all slots needing a processor have been given to the schedule plug-in,
    1.26 + * a fraction of the procrs successfully scheduled are put into the
    1.27 + * work queue, then a continuation of this function is put in, then the rest
    1.28 + * of the virt procrs that were successfully scheduled.
    1.29   *
    1.30 - *The first thing this function does is busy-wait until the previous work-unit
    1.31 - * running this function is done.  This ensures it doesn't overlap with
    1.32 - * tail-end of previous -- IE, continuation may sneak through queue before
    1.33 - * previous done putting second half of scheduled slaves in.  This is the only
    1.34 - * race condition.
    1.35 + *The first thing the continuation does is busy-wait until the previous
    1.36 + * animation completes.  This is because an (unlikely) continuation may
    1.37 + * sneak through queue before previous continuation is done putting second
    1.38 + * part of scheduled slaves in, which is the only race condition.
    1.39   *
    1.40   */
    1.41  
    1.42  /*May 29, 2010 -- birth a Master during init so that first core loop to
    1.43 - * start running gets it and does all the stuff for a newly born
    1.44 - * from then on, will be doing continuation -- but do suspension self
    1.45 + * start running gets it and does all the stuff for a newly born --
    1.46 + * from then on, will be doing continuation, but do suspension self
    1.47   * directly at end of master loop
    1.48   *So VMS__init just births the master virtual processor same way it births
    1.49   * all the others -- then does any extra setup needed and puts it into the
    1.50   * work queue.
    1.51   *However means have to make masterEnv a global static volatile the same way
    1.52   * did with workQ in core loop.  -- for performance, put the
    1.53 - * jump to core loop directly in here, and have it directly jump back.
    1.54 + * jump to the core loop directly in here, and have it directly jump back.
    1.55   */
    1.56  void masterLoop( void *initData, VirtProcr *masterPr )
    1.57 - { bool8 success;
    1.58 + { bool8 retCode;
    1.59     int slotIdx, numScheduled, numInFirstChunk, filledSlotIdx;
    1.60     SchedSlot      *currSlot, **schedSlots, **filledSlots;
    1.61     MasterEnv      *masterEnv;
    1.62 -   QueueStruc     *workQ;
    1.63 -//   VirtProcr      *masterPr;
    1.64 +   CASQueueStruc  *workQ;
    1.65     void           *jmpPt;
    1.66     
    1.67     SlaveScheduler  slaveScheduler;
    1.68 @@ -73,6 +68,7 @@
    1.69  
    1.70        //if another reference to same Master VirtProcr still going, busy-wait
    1.71        //Could put this lower, but don't want to think about shared stack..
    1.72 +   masterEnv = _VMSMasterEnv;
    1.73     while( masterEnv->stillRunning ) /*busy wait*/ ;
    1.74        //TODO: want to do busy-wait as assembly, to be sure stack not touched?
    1.75     
    1.76 @@ -82,12 +78,11 @@
    1.77        //TODO: gdb -- check that a volatile _VMSMasterEnv and _VMSWorkQ means
    1.78        // all these will be re-filled every time jump here..
    1.79     workQ            = _VMSWorkQ;
    1.80 -   masterEnv        = _VMSMasterEnv;
    1.81     requestHandler   = masterEnv->requestHandler;
    1.82     slaveScheduler   = masterEnv->slaveScheduler;
    1.83     schedSlots       = masterEnv->schedSlots;
    1.84     filledSlots      = masterEnv->filledSlots;
    1.85 -   masterPr         = masterEnv->masterVirtPr;
    1.86 +   masterPr         = masterEnv->masterVirtPr;  //post-jmp clobbered, re-load
    1.87     
    1.88  
    1.89        //prepare for scheduling
    1.90 @@ -108,10 +103,10 @@
    1.91         }
    1.92        if( currSlot->needsProcrAssigned )
    1.93         {    //give slot a new virt procr
    1.94 -         success =
    1.95 +         retCode =
    1.96           (*slaveScheduler)( currSlot, masterEnv->semanticEnv );
    1.97           
    1.98 -         if( success )
    1.99 +         if( retCode == 1 )
   1.100            { int numFilled = masterEnv->numFilled;
   1.101  
   1.102              filledSlots[numFilled] = currSlot;
   1.103 @@ -119,6 +114,12 @@
   1.104  
   1.105              currSlot->needsProcrAssigned = FALSE;
   1.106            }
   1.107 +         else if( retCode == -1 ) //scheduler plug-in says to shut down VMS
   1.108 +          {
   1.109 +            //shutdown -- make "end Thd" virt-procs whose nextInstrPt is the
   1.110 +            // coreloop's EndCoreLoopPt -- causing a jump to the EndThread
   1.111 +            // and any other shut-down.
   1.112 +          }
   1.113         }
   1.114      }
   1.115  
   1.116 @@ -126,17 +127,17 @@
   1.117     numInFirstChunk = masterEnv->numFilled / 2;  //tweak this from experiments
   1.118     for( filledSlotIdx = 0; filledSlotIdx < numInFirstChunk; filledSlotIdx++)
   1.119      {
   1.120 -      writeQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ );
   1.121 +      writeCASQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ );
   1.122      }
   1.123  
   1.124        //enqueue continuation of this loop
   1.125        // note that After this enqueue, continuation might sneak through
   1.126 -   writeQ( schedSlots[0]->procrAssignedToSlot, workQ );//master always slot 0
   1.127 +   writeCASQ( schedSlots[0]->procrAssignedToSlot, workQ );//master always slot 0
   1.128     for( filledSlotIdx = numInFirstChunk;
   1.129          filledSlotIdx < numScheduled;
   1.130          filledSlotIdx++)
   1.131      {
   1.132 -      writeQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ );
   1.133 +      writeCASQ( filledSlots[ filledSlotIdx ]->procrAssignedToSlot, workQ );
   1.134      }
   1.135  
   1.136     masterEnv->numFilled = 0;