Tasking and preemption

Tasking and preemption

[Thomas Handler]

Hi to everyone!

I'm trying to get into Ada and have now passed the tasking mechanism
provided by Ada95.
My problem is that my understanding of preempting seems not to match
with that of my system ;-)

I'm using GNAT 3.09p on Linux with libpthreads and when doing a simple
program with two tasks where each task body is simply puttnig a string
in a loop to the screen the tasks seem to have a real cooperative
behavior, i.e. Task B starts working after Task A has finished
(independent of the length of the loop).
Building a delay into the loop has the desired effect.

So my question is: In the RM preemption is based on calling blocking
statements (like delay), as far as I understand there is no definition
of thread supported preemption. Is this true (i.e. I have to take care
in my program to make calls to blocking statements) or am I terribly
wrong?

Any hints will be greatly appreciated

Thomas Handler

Re: Tasking and preemption

[dennison]

In article <36714AA1.96BD1AC5@systems.at>,
  Thomas Handler <thandler@systems.at> wrote:
> Hi to everyone!
>
> I'm trying to get into Ada and have now passed the tasking mechanism
> provided by Ada95.
> My problem is that my understanding of preempting seems not to match
> with that of my system ;-)
>
> I'm using GNAT 3.09p on Linux with libpthreads and when doing a simple
> program with two tasks where each task body is simply puttnig a string
> in a loop to the screen the tasks seem to have a real cooperative
> behavior, i.e. Task B starts working after Task A has finished
> (independent of the length of the loop).
> Building a delay into the loop has the desired effect.

Feel fortunate its working that way. Text_IO is typically not task-safe. You
shouldn't be trying to write to the same file (the screen counts as a file)
from two different concurrently-running tasks.


> So my question is: In the RM preemption is based on calling blocking
> statements (like delay), as far as I understand there is no definition
> of thread supported preemption. Is this true (i.e. I have to take care
> in my program to make calls to blocking statements) or am I terribly
> wrong?

There are multitudes of different scheduling policies that your system could
be using. The only predfined one is FIFO_Within_Priorities (D.2.2). Under
this policy a running task could concieveably hog the CPU forever unless it
performs a rendezvous, accept, or a delay. Check out Annex D of the LRM. It
has a very thourough treatment of this subject.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Tasking and preemption

[Thomas Handler]

dennison@telepath.com wrote:
> 
> In article <36714AA1.96BD1AC5@systems.at>,
>   Thomas Handler <thandler@systems.at> wrote:
> > Hi to everyone!
> >
> > I'm trying to get into Ada and have now passed the tasking mechanism
> > provided by Ada95.
> > My problem is that my understanding of preempting seems not to match
> > with that of my system ;-)
> >
> > I'm using GNAT 3.09p on Linux with libpthreads and when doing a simple
> > program with two tasks where each task body is simply puttnig a string
> > in a loop to the screen the tasks seem to have a real cooperative
> > behavior, i.e. Task B starts working after Task A has finished
> > (independent of the length of the loop).
> > Building a delay into the loop has the desired effect.
> 
> Feel fortunate its working that way. Text_IO is typically not task-safe. You
> shouldn't be trying to write to the same file (the screen counts as a file)
> from two different concurrently-running tasks.
OK, it was not a quite good example using Text_IO but it was just for a
test ;-)

> 
> > So my question is: In the RM preemption is based on calling blocking
> > statements (like delay), as far as I understand there is no definition
> > of thread supported preemption. Is this true (i.e. I have to take care
> > in my program to make calls to blocking statements) or am I terribly
> > wrong?
> 
> There are multitudes of different scheduling policies that your system could
> be using. The only predfined one is FIFO_Within_Priorities (D.2.2). Under
> this policy a running task could concieveably hog the CPU forever unless it
> performs a rendezvous, accept, or a delay. Check out Annex D of the LRM. It
> has a very thourough treatment of this subject.
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 ?)
c.) use a different (implementation dependant) scheduling policy (BTW:
which task dispatching policies are defined for GNAT?)

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.

Ciao,

Thomas Handler

> 
> --
> T.E.D.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Tasking and preemption

[Mats Weber]

On most UNIX systems, GNAT can use two different thread packages: Native
and FSU. There should be a file named README.TASKING or something like
that in your GNAT distribution and you really want to read it so that
you can choose which threads package to use.

Re: Tasking and preemption

[dennison]

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    

Re: Tasking and preemption

[Thomas Handler]

dennison@telepath.com wrote:
> 
> In article <36714AA1.96BD1AC5@systems.at>,
>   Thomas Handler <thandler@systems.at> wrote:
> > Hi to everyone!
> >
> > I'm trying to get into Ada and have now passed the tasking mechanism
> > provided by Ada95.
> > My problem is that my understanding of preempting seems not to match
> > with that of my system ;-)
> >
> > I'm using GNAT 3.09p on Linux with libpthreads and when doing a simple
> > program with two tasks where each task body is simply puttnig a string
> > in a loop to the screen the tasks seem to have a real cooperative
> > behavior, i.e. Task B starts working after Task A has finished
> > (independent of the length of the loop).
> > Building a delay into the loop has the desired effect.
> 
> Feel fortunate its working that way. Text_IO is typically not task-safe. You
> shouldn't be trying to write to the same file (the screen counts as a file)
> from two different concurrently-running tasks.
OK, it was not a quite good example using Text_IO but it was just for a
test ;-)

> 
> > So my question is: In the RM preemption is based on calling blocking
> > statements (like delay), as far as I understand there is no definition
> > of thread supported preemption. Is this true (i.e. I have to take care
> > in my program to make calls to blocking statements) or am I terribly
> > wrong?
> 
> There are multitudes of different scheduling policies that your system could
> be using. The only predfined one is FIFO_Within_Priorities (D.2.2). Under
> this policy a running task could concieveably hog the CPU forever unless it
> performs a rendezvous, accept, or a delay. Check out Annex D of the LRM. It
> has a very thourough treatment of this subject.
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 ?)
c.) use a different (implementation dependant) scheduling policy (BTW:
which task dispatching policies are defined for GNAT?)

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.

Ciao,

Thomas Handler

> 
> --
> T.E.D.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own