Re: [sv-bc] Update to Scheduling proposal for reballot issue

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Jul 07 2005 - 12:45:04 PDT
Karen Pieper wrote:

 > Hi, all,
 >
 > A new proposal for Mantis issue 794 (event scheduling) has been
 > uploaded in response to feedback we have received on the original
 > proposal.  Please review and offer feedback if you have any.
 > We will be voting on this issue and the others in the reballot
 > spreadsheet in  Friday's Champions meeting.


With respect to the new scheduling section (Mantis 794),
the diagram is fine, but I don't think the pseudocode is
correct (i.e. consistent with the diagram).

Here is what is in the proposal:

-------------------

     execute_time_slot
     {
         execute_region (preponed);
         execute_region (pre-active);
<1>     while (any region in [active ... pre-postponed] is non-empty) {
             while (any region in [active ... post-observed] is non-empty) {
                 execute_region (active);
                 R = first non-empty region in [active ... post-observed];
                 if (R is non-empty)
                     move events in R to the active region;
             }
             while (any region in [reactive ... re-inactive] is non-empty) {
                 execute_region (reactive);
                 R = first non-empty region in [reactive ... re-inactive];
                 if (R is non-empty)
                     move events in R to the reactive region;
             }
             if (pre-postponed is non-empty)
                 execute_region (pre-postponed);
         }
         execute_region (postponed);
     }

-------------------

Note that we don't get back to <1> without doing the
pre-postponed (if there is anything there).  So any
cbAtEndOfSimTime happens before the loop back.

That isn't what is intended by the diagram.

Here are two corrected variants of the pseudocode:


-------------------
Variant 1
-------------------

     execute_time_slot
     {
         execute_region (preponed);
         execute_region (pre-active);
         while (any region in [active ... pre-postponed] is non-empty) {
             while (any region in [active ... re-inactive] is non-empty) {
                 while (any region in [active ... post-observed] is non-empty) {
                     execute_region (active);
                     R = first non-empty region in [active ... post-observed];
                     if (R is non-empty)
                         move events in R to the active region;
                 }
                 while (any region in [reactive ... re-inactive] is non-empty) {
                     execute_region (reactive);
                     R = first non-empty region in [reactive ... re-inactive];
                     if (R is non-empty)
                         move events in R to the reactive region;
                 }
             }
             execute_region (pre-postponed);
         }
         execute_region (postponed);
     }

-------------------
Variant 2
-------------------

     execute_time_slot
     {
         execute_region (preponed);
         execute_region (pre-active);
         while (any region in [active ... pre-postponed] is non-empty) {
             while (any region in [active ... post-observed] is non-empty) {
                 execute_region (active);
                 R = first non-empty region in [active ... post-observed];
                 if (R is non-empty)
                     move events in R to the active region;
             }
             while (any region in [reactive ... re-inactive] is non-empty) {
                 didReactive = TRUE;
                 execute_region (reactive);
                 R = first non-empty region in [reactive ... re-inactive];
                 if (R is non-empty)
                     move events in R to the reactive region;
             }
             if (all regions in [active ... re-inactive] are empty)
                 execute_region (pre-postponed);
         }
         execute_region (postponed);
     }
-------------------


The triple loop form (Variant 1) is probably preferable, but either form
is acceptable.


Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
Received on Thu Jul 7 12:45:13 2005

This archive was generated by hypermail 2.1.8 : Thu Jul 07 2005 - 12:46:11 PDT