From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.edu:2870 comp.lang.ada:3129 comp.lang.misc:3831
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!wtwolfe
From: wtwolfe@hubcap.clemson.edu (Bill Wolfe)
Newsgroups: comp.edu,comp.lang.ada,comp.lang.misc
Subject: Teaching Concurrency
Message-ID: <7588@hubcap.clemson.edu>
Date: 7 Jan 90 02:26:35 GMT
Organization: Clemson University, Clemson, SC
List-Id: <comp.lang.ada>


   Some excerpts from an interesting article on the teaching of
   concurrency which can be found on pages 40-41 of ACM SIGAda
   Ada Letters, Volume VII, #5, Sep/Oct 1987 ("Experiences Teaching 
   Concurrency In Ada", Ronald J. Leach):

      The students were each assigned a project for which they 
      were required to write two Ada programs which involved at
      least two tasks.  In general, the tasks involved some simple
      idea that the students were very familiar with, at least in
      the case of sequential programs.  Thus, the difficulty was
      in understanding the concurrency and not in the computation
      performed by the individual task.  As an example, one student
      was asked to write a program with two tasks -- sort an array
      of integers and then search for a key using a binary search.
      The student was allowed to use any sorting algorithm.  Thus
      the student did not have difficulty implementing the individual
      algorithms for the tasks.  The troublesome part was the
      implementation of the synchronization or communication of the tasks.

      [...] Students were required to run their programs four times with
      the same input.  Most of the errors in the programs due to subtle
      assumptions about tasking made by the programmer became apparent
      after four runs.  Students' observations on this point were
      interesting.  In spite of several lectures on timing and
      synchronization of tasks, lengthy discussions on the nature of
      an Ada "logical processor", and numerous examples, students did
      not believe that programs could give different results or bomb
      when given the same input.  The sudden shock when THEIR program
      showed this behavior put the point across better than any lecture
      could.  Many of the students indicated that they had seen this kind
      of error at some time during program development.  Two of the students
      were so shocked by the different behavior of the sample runs that they
      turned in their projects with signatures of witnesses that their
      programs ran successfully at least once.  [...]
 
      ------ Other examples given of concurrent programming exercises ------

      1. Write a program which uses two tasks to solve quadratic equations
         using the quadratic formula.  Each task must perform at least 3
         arithmetic operations.

      2. Write a program to read an integer N and to have two tasks.  The
         tasks are to compute some simple function f(N) and to find all
         primes less than f(N).

      3. Write a program to simulate the donning of socks and shoes.  
         Putting on socks and putting on shoes are to be separate tasks.

      4. Write a program to read an array A of integers and to have two 
         tasks.  The tasks are to sort the array A in increasing order,
         passing this sorted array to B, and to sort the array B in 
         decreasing order.