Re: tasks, simple question

[tmoran@bix.com]

>What I am wondering is where and when one would use them.
  That is not a "simple question".

  Tasks, like subroutines, help you separate a big, complicated,
problem into a set of small, simple ones.  Usually an application
will divide rather clearly into a collection of fairly independent
activities.  If those activities occur sequentially, you use a
series of subroutine calls.  If some of those activities naturally
need to, or can, occur simultaneously, then tasks might be
appropriate.  If you have multiple CPUs, then your program will
complete faster if you can put different tasks on different CPUs
and thus overlap the time they take.

  Say you have a program that accepts a number from the user, then
calculates away for 10 seconds, displays an answer, and then waits
for the next input.  You are asked to convert that to a program
that does the same for each of 10 different users.  You could write
something that switches back and forth between scanning the 10
input lines for requests, calculating answers for anyone who has
submitted a complete request, and sending results.  It's probably a
lot easier to simply convert your procedure to a task type, then
declare multiple tasks of that type, one per input line, and let
them all run.

  Suppose you need to save away the audio and video from a TV
program onto your hard disk for later playback.  Suppose further
that you get one field of video every 1/60 second, and one buffer
load of audio every 20 ms (1/50 second).  You could write a program
that processes on a 1/300 second cycle, handling 1/5 of a video
field and 1/6 of a sound buffer each time.  Now make the problem
nastier by allowing the end user to vary the sound quality, which
means a fixed size buffer fills up in different lengths of time.
It might be much simpler to run two tasks, one for video and one
for audio, each with the cycle time it finds most convenient.

  Suppose there are several different algorithms you can use to
solve a certain type of problem, with different algorithms taking
very different lengths of time depending on the particular data.
One possible approach is to start up one task for each algorithm,
and the first one to finish tells the others to quit.  If you have
a multiple CPU machine, and one algorithm(task) per CPU, that's an
obvious way to get the answer as quickly as possible.  Even if you
had to share a single CPU, if the running times of different
algorithms are extremely different (and unpredictable), this
approach might still be better than the "put all your eggs in one
basket" approach of running algorithm A until it succeeds or you
give up, then try with algorithm B, etc.

  Task interactions usually take significantly longer than simple
procedure calls, and you can do nasty things with tasks getting in
each other's way, but they can be a powerful way to structure, or
even to speed up, an application.