1.1 --- a/MasterLoop.c	Fri Mar 09 22:30:26 2012 -0800
     1.2 +++ b/MasterLoop.c	Sat Mar 10 20:35:38 2012 -0800
     1.3 @@ -41,7 +41,7 @@
     1.4   *
     1.5   */
     1.6  
     1.7 -/*May 29, 2010 -- birth a Master during init so that first core loop to
     1.8 +/*May 29, 2010 -- birth a Master during init so that first core controller to
     1.9   * start running gets it and does all the stuff for a newly born --
    1.10   * from then on, will be doing continuation, but do suspension self
    1.11   * directly at end of master loop
    1.12 @@ -49,8 +49,8 @@
    1.13   * all the others -- then does any extra setup needed and puts it into the
    1.14   * work queue.
    1.15   *However means have to make masterEnv a global static volatile the same way
    1.16 - * did with readyToAnimateQ in core loop.  -- for performance, put the
    1.17 - * jump to the core loop directly in here, and have it directly jump back.
    1.18 + * did with readyToAnimateQ in core controller.  -- for performance, put the
    1.19 + * jump to the core controller directly in here, and have it directly jump back.
    1.20   *
    1.21   *
    1.22   *Aug 18, 2010 -- Going to a separate MasterVP for each core, to see if this
    1.23 @@ -62,7 +62,7 @@
    1.24   * animates this function has a different one.
    1.25   *
    1.26   *At this point, the masterLoop does not write itself into the queue anymore,
    1.27 - * instead, the coreLoop acquires the masterLock when it has nothing to
    1.28 + * instead, the coreCtlr acquires the masterLock when it has nothing to
    1.29   * animate, and then animates its own masterLoop.  However, still try to put
    1.30   * several AppSlvs into the queue to amortize the startup cost of switching
    1.31   * to the MasterVP.  Note, don't have to worry about latency of requests much
    1.32 @@ -164,7 +164,7 @@
    1.33  
    1.34           MEAS__Capture_Post_Master_Point;
    1.35     
    1.36 -   masterSwitchToCoreLoop(animatingSlv);
    1.37 +   masterSwitchToCoreCtlr(animatingSlv);
    1.38     flushRegisters();
    1.39     }//MasterLoop
    1.40  
    1.41 @@ -260,7 +260,7 @@
    1.42   *Note, have single-reader, single-writer pattern for all variables used to
    1.43   * communicate between stealer and victims
    1.44   *
    1.45 - *So, scan the queues of the core loops, until find non-empty.  Each core
    1.46 + *So, scan the queues of the core controllers, until find non-empty.  Each core
    1.47   * has its own list that it scans.  The list goes in order from closest to
    1.48   * furthest core, so it steals first from close cores.  Later can add
    1.49   * taking info from the app about overlapping footprints, and scan all the
    1.50 @@ -316,7 +316,7 @@
    1.51        //have a victim core, now get the stealer-lock
    1.52     gotLock =__sync_bool_compare_and_swap( &(_VMSMasterEnv->workStealingLock),
    1.53                                                            UNLOCKED, LOCKED );
    1.54 -   if( !gotLock ) return; //go back to core loop, which will re-start master
    1.55 +   if( !gotLock ) return; //go back to core controller, which will re-start master
    1.56  
    1.57  
    1.58     //====== Start Gate-protection =======