Re: Teaching Concurrency

[manis@cs.ubc.ca (Vincent Manis)]

In article <602@agcsun.UUCP> marks@agcsun.UUCP (Mark Shepherd) writes:
>Although these programming assignments evidently had some valuable lessons
>on multi-tasking, I feel that they may also inadventantly teach a
>less desirable lesson: that it is OK to use concurrent tasks for things 
>that could be done much more simply with subroutines. 
>
>In real life (whether industrial, business, scientific research, or whatever),
>multi-tasking applications carry substantial penalties
>in complexity and resource utilization, and should only be used when
>appropriate. (Of course, NOT using tasking when it should be used has  
>equally dire consequences). 
Ah, but this assumes an environment in which parallel execution is
indeed less `efficient' than serial execution. That is indeed true if
one is operating on a single CPU in which parallelism is simulated, but
what about the use of highly parallel architectures or even networks? 

It seems clear that Mark had an underlying processor model in mind when
he wrote his article. Unfortunately, that processor model is becoming
ever less common, what with the advent of both distributed network
architectures such as NCS and ONC, as well as systems such as the
Connection Machine. 

In any case, what `efficiency' metric is one using? I have seen
commercial programs in which parallelism is ever so cleverly avoided, by
use of asynchronous system traps and the like, coupled with a knowledge
of how long an operation is expected to take. David Parnas even talks of
a real-time control system (I think it was one of the Navy plane systems
he consulted on, but I'm not sure) in which code for various tasks was
interleaved at assembly time, with the programmer expected to know when
to switch instruction streams. Surely readability, maintainability,
reliability etc., are at least as important as raw speed. (Note that I
am *not* claiming that parallelism always enhances readability or
reliability; just sometimes.)

All of this leads to two observations: first, that rather than teaching
students to do particular things `because it's efficient', we ought to
teach them to look at the underlying processor architecture, as well as
the other criteria which are important in the project, before selecting
particular design techniques. Second, don't expect `efficiency' to stay
the same for any length of time; my favourite quotation from IBM's
original PL/I manual (ca. 1966) is `Do not use procedures; they are
expensive.' 

Disclaimer: I have not read the article Bill Wolfe referred to, and
therefore can't comment on the appropriateness of the original examples.
Whenever I see the word `Ada', my eyes glaze over, and I turn the page. 


--
\    Vincent Manis <manis@cs.ubc.ca>      "There is no law that vulgarity and
 \   Department of Computer Science      literary excellence cannot coexist."
 /\  University of British Columbia                        -- A. Trevor Hodge
/  \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394