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,c7cbae112ac5e4c3 X-Google-Attributes: gid103376,public From: dennison@telepath.com Subject: Re: Tasking and preemption Date: 1998/12/14 Message-ID: <753ahn$1un$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 422135592 References: <36714AA1.96BD1AC5@systems.at> <74rr7n$4sp$1@nnrp1.dejanews.com> <3674433D.9932AFF@umundum.vol.at> X-Http-Proxy: 1.0 x10.dejanews.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Mon Dec 14 15:23:37 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.5 [en] (WinNT; I) Date: 1998-12-14T00:00:00+00:00 List-Id: In article <3674433D.9932AFF@umundum.vol.at>, Thomas Handler wrote: > dennison@telepath.com wrote: > I have read this annex several times in LRM and AARM and with your above > answer it seems that I got itz the right way. > So this does actually mean that having a task that does heavy > computations has to be written > a.) in a way that ensures that a blocking statement will be executed > from time to time > b.) this task runs on lower priority and the other tasks execute a > blocking statement (will this work ?) Only as long as all higher-priority tasks are blocked. Once a higher priority task becomes ready to execute again (eg: its "delay" statement expires), it will preempt the lower-priority task again. > c.) use a different (implementation dependant) scheduling policy (BTW: > which task dispatching policies are defined for GNAT?) Yes. But note that the RM does not require that your compiler's *default* scheduling policy be FIFO_Within_Priorities. I'd expect compilers to default to something that matches the default behavior of OS threads on the target platform. For instance, on an SMP machine (eg: A dual processor PC clone running NT), I'd expect (or at least hope!) to see *two* threads running when possible. > I have to admit that I have not used threads ever before on Unix due to > the fact that I have gained some experiences with them on a propietary > system developed by my former employer. After a look on the PThread > documentation I decided not to use them with C/C++ since the latter of > the combination itself is already troublesome :-) > But it seems strange to me since my understanding of threads always was > that they are preempting (that's why you a thread-safe library will help > a lot ;-) and GNAT uses libpthread. So I'm a bit surprised at the > moment. They do preempt. If a higher priority task becomes ready, it will preempt the lower-priority task with the CPU. It sounds like you are talking about *time-slicing* within priorities. I'd expect to see that on some platforms. But if your tasks aren't continually working, this is actully less efficient; all those context switches chew up time. Better to let each run to completion. Time-slicing also considerably complicates proving schedulability. Yes, you do have the (rare) problem of CPU starvation. That's typicaly a design problem. Generally, tasks should either: o start up, do their job, then quit. o repeatedly wait for input notification via a rendezvous, then work until all the input has been processed. o use "delay" or "delay until" statements to periodicly wakeup and process the current state of their input at a certain rate (like 60Hz). -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own