Re: Tasking and preemption

[dennison@telepath.com]

In article <3674433D.9932AFF@umundum.vol.at>,
  Thomas Handler <th@umundum.vol.at> 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