Re: Teaching Concurrency

[sccowan@watmsg.waterloo.edu (S. Crispin Cowan)]

In article <602@agcsun.UUCP> marks@agcsun.UUCP (Mark Shepherd) writes:
>I have seen large (and expensive!) systems crippled by inappropriate use
>of tasking, and I hope the the computer science graduates of the future
>will understand not only HOW to use multi-tasking, but WHEN.

When to use tasking critically depends on the cost of the tasking
operations.  Under UNIX, a context switch costs something on the order
of 1 or 2 ms, and forking somewhat more.  Under VMS, task creation is
much more expensive, but task switching is much cheaper, so a larger
number of tasks in a more static process structure is more
appropriate.

In the OS/Architecture project that I work in (Sylvan), light-weight
tasking is the objective, so that tasks CAN be used in place of
subroutines (at least big ones that have potential for concurrency).
Sending a message to a server and getting a response back has a cost
overhead of 100 to 200 microseconds.

The bottom line is that any unit of abstraction (subroutines, tasks,
objects, etc.) should be used to a level of granularity/modularity
that is appropriate, depending on the cost of the abstraction, in both
time and space.  Subroutines to add two integers are not appropriate,
similarly UNIX tasks to perform similarly small operations are not
appropriate.  Of course, if performance is not an issue, then the
appropriate level of modularity is that which makes the program the
easiest to read/write/maintain.

>Mark Shepherd
>agcsun!marks@boulder.colorado.edu

----------------------------------------------------------------------
(S.) Crispin Cowan, CS grad student, University of Waterloo
Office:		DC3548	x3934		Home phone: 570-2517
Post Awful:	60 Overlea Drive, Kitchener, N2M 1T1
UUCP:		watmath!watmsg!sccowan
Domain:		sccowan@watmsg.waterloo.edu

"The most important question when any new computer architecture is
introduced is `So what?'"
	-someone on comp.arch
	(if it was you, let me know & I'll credit it)