Re: Teaching Concurrency

[firth@sei.cmu.edu (Robert Firth)]

In article <=K01QVDxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>I believe that the following two problems are inappropriate, because
>they are subject to race conditions related to task startup time,
>quantum sizes, and so on:
>
>> (3) veryslowsort.
>> (6) quantum mouse.

Thanks, Peter; my note omitted a couple of key points.  Please
let me clarify

(a) the exercises were intended to teach concurrency on ONE
    processor, as a preparatory to building a small local
    operating system.  (multiprocessor concurrency, and
    concurrency models transparent to number of processors,
    were covered elsewhere)

(b) the underlying model had, and relied upon, a scheduler
     whose operation was defined precisely.  the examples
    in part illustrated this.  however, the students were
    emphatically taught that, in real life, one does NOT
    rely on priority to effect ordering of task execution.

For example, the commentary explaining 'veryslowsort' pointed
out that

(1) the process reading input and creating tasks had the highest
    priority, so all the input would be read before any of the
    printing tasks ran

(2) the scheduler used strict priorities, so indeed the printing
    tasks would be run in the right order to print a sorted list

I didn't think it necessary to add that this was a pretty silly
way to sort numbers - the name alone seemed hint enough.  The
fact that the program in execution exhibits no concurrency at all
is one the students were able to deduce for themselves.