home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / modula2 / mod2txt.arc / CHAP15.TXT < prev    next >
Text File  |  1987-03-25  |  14KB  |  322 lines
  1.                          Chapter 15 - Concurrency
  2.  
  3.  
  4.                       PREREQUISITES FOR THIS MATERIAL
  5.  
  6.              In  order to understand this material you should have a
  7.         good grasp of the material in Part I of this tutorial and at
  8.         least  a  cursory  knowledge of the material in  chapter  14
  9.         concerning  the pseudo module SYSTEM and especially the  ADR
  10.         and SIZE functions.
  11.  
  12.                             WHAT IS CONCURRENCY
  13.  
  14.              True concurrency is when two processes are taking place
  15.         at exactly the same time with neither affecting the other in
  16.         a  degrading  way.   This is possible in many areas of  your
  17.         life,  such as when the Grandfather clock is running at  the
  18.         same time as the furnace and the television set.   These are
  19.         different  processes all running at the same time.   In  the
  20.         field  of computers,  true concurrency requires at least two
  21.         separate  processors  that are running  completely  separate
  22.         programs or different parts of the same program.
  23.  
  24.              Usually,   when  computers  are  said  to  be   running
  25.         concurrent  processes,  reference  is being made to  a  time
  26.         sharing  situation in which two or more programs are swapped
  27.         in and out of the computer at a rapid rate,  each getting  a
  28.         small  slice  of time,  a millisecond being  typical.   Each
  29.         process appears to be running constantly but is in fact only
  30.         running a small part of the time,  sort of stuttering.   The
  31.         swapping  in  and out is taking place so fast that,  to  the
  32.         casual user,  it appears that the entire computer is working
  33.         on only his program.
  34.  
  35.                        WHAT IS MODULA-2 CONCURRENCY?
  36.  
  37.              The  process in Modula-2,  which is called concurrency,
  38.         is  neither  of the above,  and it should  probably  not  be
  39.         called concurrency.  It is a new way to call and return from
  40.         procedures,  and  although  it is possible to use  this  new
  41.         method of procedure linkage to simulate something that looks
  42.         like concurrent processes,  it is not true concurrency.   It
  43.         is  a part of the language,  and a useful part,  so we  will
  44.         cover it in this chapter.
  45.  
  46.                             OUR FIRST COROUTINE
  47.  
  48.              Load  and display the program named COROUT.MOD for  our
  49.         first   look  at  this  new  technique.    Without  lots  of
  50.         explanation,  there are lots of new items IMPORTED and a few
  51.         variables defined, the most interesting being the three that
  52.         are  defined  as  PROCESS type.   These will  be  the  three
  53.         processes we will use in this example.   Next, there are two
  54.         PROCEDURES  which define what the coroutines  will  do.   It
  55.  
  56.  
  57.                                  Page 94
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.                          Chapter 15 - Concurrency
  68.  
  69.  
  70.         must  be noted that these PROCEDURES are not allowed to have
  71.         any formal parameters in their headers.   Finally we come to
  72.         the main program which is where we will start to define  how
  73.         to use the coroutines.
  74.  
  75.              First,  in the main program, we call "NEWPROCESS" which
  76.         loads  a  new process without running it.   We give  it  the
  77.         name  of the procedure where the process can be  found,  and
  78.         give  the  system  a  workspace by  assigning  a  previously
  79.         defined array to it.   This is done by giving the system the
  80.         address and the size of the array.   Finally,  we give it  a
  81.         name  by  which we can call the process.   It must be  noted
  82.         that the workspace must be sufficient for the new process to
  83.         store  all of its variables,  so give the process a generous
  84.         workspace.   If  it is too small,  a runtime error  will  be
  85.         generated.  We then load a second process in preparation for
  86.         running the program by calling NEWPROCESS again.
  87.  
  88.                          HOW DO WE GET IT STARTED?
  89.  
  90.              When we began the main program,  we actually loaded and
  91.         started  a process,  the one we are presently executing.  We
  92.         have done this for every program in this tutorial so far but
  93.         paid  no  attention  to it as far as referring to  it  as  a
  94.         process.   We have not given our running process a name yet,
  95.         but we will when we leave it because we have defined another
  96.         PROCESS  type  variable named "main".   To  start  the  next
  97.         process  we  use the TRANSFER function with the name of  the
  98.         process  we wish to terminate and the one we wish to  start.
  99.         This is illustrated in line 43 from which we jump to line 15
  100.         in the process named "Process1".  In Process1 we begin a FOR
  101.         loop where we write a string and a cardinal number then when
  102.         "Index" exceeds 2,  we do another TRANSFER,  this time  from
  103.         Process1  to  Process2.   Thus we jump from line 19  in  one
  104.         procedure  to line 31 in another where we begin an  infinite
  105.         loop.   We print another string in line 32 and once again do
  106.         a TRANSFER from line 33 to somewhere.  The place where we go
  107.         at  this  point is what makes the coroutines different  from
  108.         the standard procedure.
  109.  
  110.                WHERE DO WE GO WHEN WE RETURN TO A COROUTINE?
  111.  
  112.              Instead  of  jumping to the beginning of the  procedure
  113.         again,  which would be line 15 in this example, we return to
  114.         the statement following the one we left from.   In this case
  115.         we will return from line 33 to line 20 and complete the loop
  116.         we started earlier.   When Index is increased to 4,  we will
  117.         once again TRANSFER control from line 19 to "Process2",  but
  118.         instead  of jumping to line 31 we will return where we  left
  119.         off there at line 34.   That loop will complete, and we will
  120.         once  again  return  to  line 20.   When  the  FOR  loop  in
  121.  
  122.  
  123.                                  Page 95
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.                          Chapter 15 - Concurrency
  134.  
  135.  
  136.         "Process1"  finishes,  we execute lines 24 and 25  then  the
  137.         TRANSFER  in line 26 will return us to the main module  body
  138.         where  we  will arrive at line 44 and complete the last  two
  139.         write  statements  and  do a normal exit  to  the  operating
  140.         system.
  141.  
  142.              Rather  than  a  technical discussion  of  how  to  use
  143.         coroutines,  this  example was defined step by step.   If it
  144.         was  not  clear,  reread the entire  description  until  you
  145.         understand  it.   There  is really nothing else there is  to
  146.         know  about coroutines other than that knowledge  gained  by
  147.         experience  in  using  them,   which  is  true  of  any  new
  148.         principle  in  computer  programming or any other  facet  of
  149.         life.
  150.  
  151.                           WHAT WAS ALL THAT ABOUT?
  152.  
  153.              The thing that is really different about coroutines  is
  154.         the  fact  that they are both (or all three or more)  loaded
  155.         into the computers memory and they stay loaded for the  life
  156.         of the program.   This is not true of normal procedures.  It
  157.         is  transparent  to you,  but procedures are not all  simply
  158.         loaded   into  the  computer  and  left  there,   they   are
  159.         dynamically allocated and started as they are called.   That
  160.         is  why  variables are not saved from one  invocation  of  a
  161.         procedure  to the next.   The variables within a process are
  162.         loaded once, and stay resident for the life of the program.
  163.  
  164.              In  the  example  program on your  monitor,  all  three
  165.         processss including the main program are loaded and none  is
  166.         really  the main program since any of the programs have  the
  167.         ability to call the others.
  168.  
  169.              Load  and  display COROUT2.MOD for the  second  example
  170.         with  coroutines.   This program is identical with the  last
  171.         except that two lines are removed from the first process and
  172.         placed in a normal procedure which is called from line 22 to
  173.         illustrate  that some of the code can be placed  outside  of
  174.         the  coroutine  process to make the resident  part  smaller.
  175.         The  implication  here  is that you could have  a  four  way
  176.         coprocess  going  on,  each  one of which had a  very  small
  177.         resident  portion,  and each one of which called  some  huge
  178.         regular procedures.   In fact, there is no reason why two or
  179.         more  of  the  coprocesses could not call  the  same  normal
  180.         procedure.
  181.  
  182.              Study   this   program   until   you   understand   the
  183.         implications,  then  compile and run it to see that it  does
  184.         exactly the same thing as the last program.
  185.  
  186.  
  187.  
  188.  
  189.                                  Page 96
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.                          Chapter 15 - Concurrency
  200.  
  201.  
  202.                          HOW ABOUT THREE PROCESSES?
  203.  
  204.              Load  and display COROUT3.MOD for an example with three
  205.         concurrent  processes.   This  program is identical  to  the
  206.         first program with the addition of another process.  In this
  207.         program,  process 1 calls process 2,  which calls process 3,
  208.         which  once again calls process 1.   Thus the same  loop  is
  209.         traversed  but with one additional stop along the  way.   It
  210.         should  be  evident to you that there is no reason why  this
  211.         could  not  be  extended to any  number  of  processes  each
  212.         calling the next or in any looping scheme you could think up
  213.         provided of course that it had some utilitarian purpose.
  214.  
  215.                         WHAT IS THE BIG DIFFERENCE?
  216.  
  217.              Actually,  the  big difference between real  concurrent
  218.         processing and what this is doing is in the division of time
  219.         and  in  who,  or  what,  is doing the  division.   In  real
  220.         concurrent processing,  the computer hardware is controlling
  221.         the operation of the processing and allocating time slots to
  222.         the various processes.   In the pseudo concurrent processing
  223.         we are doing,  it is the processes themselves that are doing
  224.         the  time allocation leading to the possibility that if  one
  225.         of  the  processes  went bad,  it could tie up  all  of  the
  226.         resources  of  the  system and no  other  process  could  do
  227.         anything.   You  could  consider it a challenge to  write  a
  228.         successful  system that really did share time and  resources
  229.         well.
  230.  
  231.              The important thing to consider about this technique is
  232.         that  it  is  not  a major  breakthrough  in  a  programming
  233.         language, but one additional tool available in Modula-2 that
  234.         is  not  available in the other popular  languages  such  as
  235.         Pascal, C, Fortran, or BASIC.
  236.  
  237.                   ONE MORE INFINITE EXAMPLE OF CONCURRENCY
  238.  
  239.              Load  and  display the program named  INFINITE.MOD  for
  240.         another  example  of a program with  concurrency.   In  this
  241.         program,   three   processes  are  created  and  control  is
  242.         transferred  to  the first one after which  they  call  each
  243.         other  in a loop with no provision for ever returning to the
  244.         main program.  The computer will continually loop around the
  245.         three processes checking the printer,  the keyboard, and the
  246.         system  clock  to see if they need servicing.   It  must  be
  247.         pointed out that it would be a simple matter to include  all
  248.         three  checks  in a single loop in the main program  and  do
  249.         away  with all of this extra baggage.   This method had  one
  250.         advantage  over  the simple loop and that is the  fact  that
  251.         each  coprocess  can have its own variables which cannot  be
  252.         affected by the operation of the other processes and yet are
  253.  
  254.  
  255.                                  Page 97
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.                          Chapter 15 - Concurrency
  266.  
  267.  
  268.         all memory resident at all times.
  269.  
  270.              This  program  can  be compiled and  run  but  it  will
  271.         execute  forever  since it has no way to stop it.   You  can
  272.         stop  it because it is writing to the monitor and  therefore
  273.         will be checking the control-break combination.   Simply hit
  274.         control-break  and  the program will be  terminated  by  the
  275.         operating  system.   It  should  be mentioned that  if  this
  276.         technique were used in a real situation,  it would  probably
  277.         not be writing to the monitor continually.
  278.  
  279.                            IS THIS REALLY USEFUL?
  280.  
  281.             In a situation where you needed to service interrupts in
  282.         some  prescribed and rapid fashion,  a  technique  involving
  283.         Modula-2  concurrency could prove to be very useful.   There
  284.         are other procedures available in Modula-2 to aid in writing
  285.         a pseudo-concurrent program but they are extrememly advanced
  286.         and would require  an initimate knowledge of your particular
  287.         systems hardware, especially the interrupt system.
  288.  
  289.              Since  using  these techniques are  extremely  advanced
  290.         programming techniques, they will not be covered here.  They
  291.         are beyond the scope of this tutorial.   It would be to your
  292.         advantage  to  study them and know  that  they  exist,  then
  293.         someday  you  may find that they fill the bill  and  greatly
  294.         simplify some particular programming problem.
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.                                  Page 98
  322.