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=0.6 required=5.0 tests=BAYES_05,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.edu:2903 comp.lang.ada:3168 comp.lang.misc:3878
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!agcsun!marks
From: marks@agcsun.UUCP (Mark Shepherd)
Newsgroups: comp.edu,comp.lang.ada,comp.lang.misc
Subject: Re: Teaching Concurrency
Summary: my 2 bits worth
Message-ID: <604@agcsun.UUCP>
Date: 13 Jan 90 00:06:44 GMT
References: <7588@hubcap.clemson.edu> <602@agcsun.UUCP> <499@qusundl.queensu.CA>
Organization: Ampex VSD Golden Engineering, Golden, CO
List-Id: <comp.lang.ada>

In article <499@qusundl.queensu.CA>, dalamb@qucis.queensu.CA (David Lamb) writes:
> In article <602@agcsun.UUCP> marks@agcsun.UUCP (Mark Shepherd) writes:
> >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).
> >
> This may be true now, but will it continue to be true?  

Yes. Like any other tool or technique, it will *always* be true that 
tasking should only be used when appropriate. Here is my view of some of
the circumstances under which this is the case:

- when different functions are unrelated
- when different functions have dissimilar lifetimes or priorities
- when different functions may or must run on different processors
- when a agent is needed to serialize or manage access to a 
  resource or device
- when errors must be isolated to a single sub-component of a system
- when a simpler or more effective design results (this of course is the
  acid test of appropriateness - all the "whens" are secondary)

The use of a separate task to, for example, add 2 numbers together, is 
usually inappropriate because it adds unnecessary complexity. Whether
or not it causes a performance problem depends on what the performance
requirements are. 

In the large and expensive system I alluded to in my previous posting, the
performance problems arose not because tasking was used, but because
it was *inappropriately* used. 

My view of performance or "efficiency" is that these are not absolute 
terms, but must always be viewed relative to the user's requirements. 
A program that produces results when the user needs them has good 
performance, even if it is "inefficient" (e.g. it uses PL/1 subroutines :-).
A program that will run in finite time only on a connection machine has 
good performance only if I happen to own such a machine.

Mark S