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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d576ceec8fa95166 X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: tasks, simple question Date: 1999/11/15 Message-ID: #1/1 X-Deja-AN: 548914899 References: <382FC705.29121528@interact.net.au> X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-sf.snfc21.pbi.net 942689298 206.170.2.211 (Mon, 15 Nov 1999 10:08:18 PST) Organization: SBC Internet Services NNTP-Posting-Date: Mon, 15 Nov 1999 10:08:18 PST Newsgroups: comp.lang.ada Date: 1999-11-15T00:00:00+00:00 List-Id: >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.