1.1 --- a/SSR_Request_Handlers.c	Sun Dec 04 16:43:27 2011 -0800
     1.2 +++ b/SSR_Request_Handlers.c	Tue Dec 06 05:13:00 2011 -0800
     1.3 @@ -64,8 +64,7 @@
     1.4  
     1.5  
     1.6  //===========================================================================
     1.7 -/*SendType
     1.8 - *The semantic request has the receiving processor and the message type
     1.9 +/*The semantic request has the receiving processor and the message type
    1.10   *
    1.11   *Note one value in this approach: without the extra VMS layer,
    1.12   * the send and receive would happen in real time instead of virtual time,
    1.13 @@ -147,81 +146,6 @@
    1.14      }
    1.15   }
    1.16  
    1.17 -/*Send NtoN
    1.18 - *
    1.19 - *For NtoN, the sender only specifies the setID, there is no receiving
    1.20 - * procr stated.
    1.21 - * 
    1.22 - *The semantic request has the SetID and ptr to message
    1.23 - *
    1.24 - *Each setID has its own entry in a circular buffer.  Collect the sends in
    1.25 - * a linked list inside the entry.
    1.26 - *Waiting receives also collect inside the entry -- if one there, pair
    1.27 - * it with this send.
    1.28 - *Sends can either be send-and-go or wait-for-receive.  But receives must
    1.29 - * wait for a send to pair with.
    1.30 - * 
    1.31 - *Q: how know when done with particular setID?
    1.32 - *A: requires info from app -- either register the ID w/num in set, or do a
    1.33 - *   start-end to bound it.
    1.34 - *<Dec 2011> try first with register the number in set -- means have to decr
    1.35 - * number of sends remaining, and if has a waiting receive, incr number of
    1.36 - * receives.
    1.37 - *
    1.38 - *When register a setID, state num in set, and state whether sends to that
    1.39 - * set wait to be paired with receive, or just resume right away
    1.40 - */
    1.41 -void
    1.42 -handleSendNtoN( SSRSemReq *semReq, SSRSemEnv *semEnv )
    1.43 - { SSRSemReq    *sendingReq, receiveReq;
    1.44 -   int32         setID;
    1.45 -   NtoNEntry    *entry;
    1.46 -   MovingWindow *movingWindow = semEnv->movingWindow;
    1.47 - 
    1.48 -   setID        = semReq->setID;
    1.49 -
    1.50 -   entry        = (NtoNEntry *)giveWindowEntry( setID, movingWindow );
    1.51 -   if( entry == NULL ) ERROR(); //prints this file & line
    1.52 -   
    1.53 -      //safety check: make sure number of sends not greater than expected
    1.54 -   entry->numSent += 1;
    1.55 -   if( entry->numSend > entry->numInSet ) ERROR(); //prints this file & line
    1.56 -   
    1.57 -      //check for waiting receivers
    1.58 -   receiveReq = entry->waitingReceives;
    1.59 -   if( receiveReq != NULL )
    1.60 -    { entry->waitingReceives = entry->waitingReceives->nextWaitingReq;
    1.61 -      entry->numReceived += 1;
    1.62 -      if( entry->numReceived == entry->numInSet ) 
    1.63 -         retireSet( setID, movingWindow ); //mark unused so can adv window
    1.64 -      
    1.65 -         //bring both processors back from suspend
    1.66 -      resume_procr( sendingReq->sendPr,    semEnv );
    1.67 -      resume_procr( receiveReq->receivePr, semEnv );
    1.68 -      
    1.69 -         //done
    1.70 -      return;
    1.71 -    }
    1.72 -   
    1.73 -      //Were no waiting receivers, so add this send to list
    1.74 -      // but how deps on whether sender waits or goes
    1.75 -   if( entry->senderDoesWait )
    1.76 -    { sendingReq->nextWaitingReq = entry->waitingSends;
    1.77 -      entry->waitingSends = sendingReq;
    1.78 -      return;  //sender waits, so it stays suspended, so nothing left to do
    1.79 -    }
    1.80 -   else
    1.81 -    {    //sender doesn't wait, so semReq, which is on stack, will disappear
    1.82 -         // so clone it before adding it to list, then resume sender
    1.83 -      SSRSemReq *clonedReq = cloneReq( semReq );
    1.84 -      clonedReq->nextWaitingReq = entry->waitingSends;
    1.85 -      entry->waitingSends = clonedReq;
    1.86 -      resume_procr( sendingReq->sendPr,    semEnv );
    1.87 -      return;
    1.88 -    }
    1.89 -//         DEBUG2( dbgRqstHdlr, ": %d, %d  |  ", , )
    1.90 - }
    1.91 -
    1.92  
    1.93  /*Looks like can make single handler for both sends..
    1.94   */
    1.95 @@ -311,75 +235,6 @@
    1.96   
    1.97   }
    1.98  
    1.99 -/*Receive NtoN
   1.100 - *
   1.101 - *For NtoN, the receiver only specifies the setID
   1.102 - * 
   1.103 - *The semantic request has the SetID and returns with ptr to message
   1.104 - *
   1.105 - *Each setID has its own entry in a circular buffer.  Collect the receives in
   1.106 - * a linked list inside the entry.
   1.107 - *Waiting sends also collect inside the entry -- if one there, pair
   1.108 - * it with this receive.
   1.109 - *Receives must wait for a send to pair with.
   1.110 - *  
   1.111 - *Q: how know when done with particular setID?
   1.112 - *A: requires info from app -- either register the ID w/num in set, or do a
   1.113 - *   start-end to bound it.
   1.114 - *<Dec 2011> try first with register the number in set -- means have to decr
   1.115 - * number of sends remaining, and if has a waiting receive, incr number of
   1.116 - * receives.
   1.117 - *
   1.118 - *When register a setID, state num in set, and state whether sends to that
   1.119 - * set wait to be paired with receive, or just resume right away
   1.120 - * 
   1.121 - *So, in this receive, if has a waiting send, check if it's the last
   1.122 - * receive of set.
   1.123 - *Also, either way, if the sending VPs don't wait to be paired, then any
   1.124 - * send-request that's waiting was cloned, so has to be freed.
   1.125 - */
   1.126 -void
   1.127 -handleReceiveNtoN( SSRSemReq *semReq, SSRSemEnv *semEnv )
   1.128 - { SSRSemReq    *sendReq, receiveReq = semReq;
   1.129 -   int32         setID;
   1.130 -   NtoNEntry    *entry;
   1.131 -   MovingWindow *movingWindow = semEnv->movingWindow;
   1.132 - 
   1.133 -   setID        = semReq->setID;
   1.134 -
   1.135 -   entry        = (NtoNEntry *)giveWindowEntry( setID, movingWindow );
   1.136 -   if( entry == NULL ) ERROR(); //prints this file & line
   1.137 -      
   1.138 -      //check for waiting sends
   1.139 -   sendReq = entry->waitingSends;
   1.140 -   if( sendReq != NULL )
   1.141 -    {    //remove the waiting send from list
   1.142 -      entry->waitingSends = sendReq->nextWaitingReq;
   1.143 -         //means this receive matched, so check if last in set
   1.144 -      entry->numReceived += 1;
   1.145 -      if( entry->numReceived == entry->numInSet ) 
   1.146 -         retireSet( setID, movingWindow ); //mark unused so can adv window
   1.147 -
   1.148 -         //check whether sending VP is waiting or not
   1.149 -      if( entry->senderDoesWait )
   1.150 -       {    //bring both processors back from suspend
   1.151 -         resume_procr( sendReq->sendPr,    semEnv );
   1.152 -         resume_procr( receiveReq->receivePr, semEnv );
   1.153 -       }
   1.154 -      else
   1.155 -       { VMSPlugin__free( sendReq );
   1.156 -         resume_procr( receiveReq->receivePr, semEnv );         
   1.157 -       }
   1.158 -         //done
   1.159 -      return;
   1.160 -    }
   1.161 -   
   1.162 -      //Was no waiting send, so add this to waiting receive list
   1.163 -   receiveReq->nextWaitingReq = entry->waitingReceives;
   1.164 -   entry->waitingReceives = receiveReq;
   1.165 -   return;
   1.166 -//         DEBUG2( dbgRqstHdlr, ": %d, %d  |  ", , )
   1.167 - }
   1.168  
   1.169  void
   1.170  handleReceiveType( SSRSemReq *semReq, SSRSemEnv *semEnv)

     2.1 --- a/SSR_lib.c	Sun Dec 04 16:43:27 2011 -0800
     2.2 +++ b/SSR_lib.c	Tue Dec 06 05:13:00 2011 -0800
     2.3 @@ -269,7 +269,7 @@
     2.4  
     2.5  /*
     2.6   */
     2.7 -VirtProcr *
     2.8 +  VirtProcr *
     2.9  SSR__create_procr_with( VirtProcrFnPtr fnPtr,   void *initData,
    2.10                          VirtProcr *creatingPr )
    2.11   { SSRSemReq reqData;
    2.12 @@ -288,7 +288,7 @@
    2.13     return creatingPr->dataRetFromReq;
    2.14   }
    2.15  
    2.16 -VirtProcr *
    2.17 +  VirtProcr *
    2.18  SSR__create_procr_with_affinity( VirtProcrFnPtr fnPtr, void *initData,
    2.19                          VirtProcr *creatingPr,  int32  coreToScheduleOnto )
    2.20   { SSRSemReq  reqData;
    2.21 @@ -394,69 +394,6 @@
    2.22  
    2.23  //===========================================================================
    2.24  
    2.25 -/*NtoN register a new set
    2.26 - * 
    2.27 - *Have to know when safe to retire a given setID, and also easier if make the
    2.28 - * wait-vs-go behavior of sender be defined by the set.  So, before doing
    2.29 - * and sends, perform this call to 'register' the set's ID.
    2.30 - *
    2.31 - *Give the call the setID, the number in the set, and TRUE if senders wait
    2.32 - * for a receive, else FALSE
    2.33 - */
    2.34 -void
    2.35 -SSR__register_NtoN_set( int32 setID, int32 numInSet, bool32 doesWait,
    2.36 -                        VirtProcr *animPr )
    2.37 - { SSRSemReq  reqData;
    2.38 -
    2.39 -   reqData.sendPr    = animPr;  //reuse field
    2.40 -   reqData.reqType   = register_NtoN;
    2.41 -   reqData.setID     = setID;
    2.42 -   reqData.numInSet  = numInSet;
    2.43 -   reqData.doesWait  = doesWait;
    2.44 -
    2.45 -   VMS__send_sem_request( &reqData, animPr );
    2.46 - }
    2.47 -
    2.48 -/*NtoN  send
    2.49 - *This construct doesn't specify a receiving processor, nor does it have the
    2.50 - * concept of a virtual physical communication channel.  Instead, the concept
    2.51 - * is of a set of things being sent, which are all received.  The set is
    2.52 - * unique within the computation.  The same line of code can be reused for
    2.53 - * multiple sets, by making the setID be a variable.
    2.54 - * 
    2.55 - *The benefit is in portability.  This construct specifies true
    2.56 - * non-determinism in a logically safe way, and with a pattern that exists
    2.57 - * directly in the problem being solved.
    2.58 - *For example, accumulation of results in
    2.59 - * matrix multiply has N result sends for a particular input pair, which all
    2.60 - * are accumulated into a particular result matrix.  Each input pair
    2.61 - * is a different set.
    2.62 - *The results gathering can be split amongst a variable
    2.63 - * number of processors, each owning a portion of the results matrix)
    2.64 - * 
    2.65 - *<Dec 2011> At some point, the setID can be made hierarchical.  Also, the
    2.66 - * creation of processors can be put under scheduler control with query-
    2.67 - * answer pattern for number to create.
    2.68 - * 
    2.69 - *The sending VP either waits to be matched to a receiver, or else just
    2.70 - * resumes right away.  The behavior is fixed when the setID is registered.
    2.71 - */
    2.72 -void
    2.73 -SSR__send_one_of_NtoN_set( VirtProcr *sendPr, void *msg, int setID )
    2.74 - { SSRSemReq  reqData;
    2.75 -
    2.76 -   reqData.sendPr    = sendPr;
    2.77 -   reqData.reqType   = send_NtoN;
    2.78 -   reqData.setID     = setID;
    2.79 -   reqData.msg       = msg;
    2.80 -   reqData.nextWaitingReq = NULL;
    2.81 -
    2.82 -   VMS__send_sem_request( &reqData, sendPr );
    2.83 -
    2.84 -      //When come back from suspend, no longer own data reachable from msg
    2.85 - }
    2.86 -
    2.87 -
    2.88  void
    2.89  SSR__send_of_type_to( VirtProcr *sendPr, void *msg, const int type,
    2.90                          VirtProcr *receivePr)