Ada 95 tasking problems with Ada 83 code

Ada 95 tasking problems with Ada 83 code

[Wayne Lydecker]

I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
running Linux.  Creating the executable was not a big problem, but I
can't get it to run very far.  It appears that when a procedure rendezvous'
with a task, the task won't run.  The task has a simple accept statement,
and it appears to accept the rendezvous because the calling routine
continues to process.  Text_IO calls before and after the accept statement
in the task fail to appear on the screen though.  If I put a "do ... end"
on the accept statement then the caller no longer continues (i.e.
suspended).

Is this a known problem?  Is there a solution other then removing all
tasks in our program (over 100).

Thanks,

Wayne Lydecker
wayne@visicom.com

Re: Ada 95 tasking problems with Ada 83 code

[Wayne Lydecker]

Richard Riehle wrote:
> 
> Wayne Lydecker wrote:
> 
> > I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> > running Linux.  Creating the executable was not a big problem, but I
> > can't get it to run very far.  It appears that when a procedure rendezvous'
> > with a task, the task won't run.  The task has a simple accept statement,
> > and it appears to accept the rendezvous because the calling routine
> > continues to process.  Text_IO calls before and after the accept statement
> > in the task fail to appear on the screen though.  If I put a "do ... end"
> > on the accept statement then the caller no longer continues (i.e.
> > suspended).
> >
> > Is this a known problem?  Is there a solution other then removing all
> > tasks in our program (over 100).
> >
> 
> You mention the calls to Text_IO.  This is a potential source of trouble in
> tasking, especially
> if you have any kind of Get or Get_Line statements.   Recommend looking at
> Get_Immediate,
> and Look_Ahead as possible alternatives to other Get statements.  The standard
> Get statement
> blocks waiting for input but Get_Immediate can get whatever is in the buffer
> without waiting
> for a CR/LF.
> 
> This may not be the entire source of your problem.   Although converting a
> task-based program
> from Ada 83 to Ada 95 is fairly straightforward,  you can encounter other
> problems due to timing
> issues (sometimes people put delay statements into task-based programs),
> mutual exclusion
> problems (the use of task-based semaphores instead of protected objects), and
> other little gotchas
> that result in a compiled program that will not run as expected.   Another
> possibility is schedulability.
> For example, are all the tasks at the same level of priority?    Have you done
> a careful analysis of
> the schedulability of the design using RMA tools?    With over 100 tasks, it is
> essential that you
> examine the schedulability issue using contemporary mathematical tools such as
> RMA.
> 
> Do not automatically assume you must eliminate tasking from your program.
> Properly designed,
> tasking can work quite well and give your program a level of robust perfomance
> you might not
> otherwise be able to easily achieve.  This is especially true of the Ada 95
> tasking model.
> 
> Richard Riehle

Thanks Richard.  I put in the text_IO.Put_Line calls to help diagnose the
problem.  No get's.  The debugger was not giving me enough information
(probably because it gdbtk is new to me).

There are delay statements in the select statements but I am having problems
with the "accept init;" which allows the task to start executing.  I don't
get the text_io.put_line call I put in immediately after it.

I am unfamiliar with RMA.  I will look into it.  My next approach will be
to write a simple program to see if I can duplicate it easily.  Then I
can publish that and see if others experience the same problem I am.

Thanks again,

Wayne.

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Wayne Lydecker wrote:

> I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> running Linux.  Creating the executable was not a big problem, but I
> can't get it to run very far.  It appears that when a procedure rendezvous'
> with a task, the task won't run.  The task has a simple accept statement,
> and it appears to accept the rendezvous because the calling routine
> continues to process.  Text_IO calls before and after the accept statement
> in the task fail to appear on the screen though.  If I put a "do ... end"
> on the accept statement then the caller no longer continues (i.e.
> suspended).
>
> Is this a known problem?  Is there a solution other then removing all
> tasks in our program (over 100).
>

You mention the calls to Text_IO.  This is a potential source of trouble in
tasking, especially
if you have any kind of Get or Get_Line statements.   Recommend looking at
Get_Immediate,
and Look_Ahead as possible alternatives to other Get statements.  The standard
Get statement
blocks waiting for input but Get_Immediate can get whatever is in the buffer
without waiting
for a CR/LF.

This may not be the entire source of your problem.   Although converting a
task-based program
from Ada 83 to Ada 95 is fairly straightforward,  you can encounter other
problems due to timing
issues (sometimes people put delay statements into task-based programs),
mutual exclusion
problems (the use of task-based semaphores instead of protected objects), and
other little gotchas
that result in a compiled program that will not run as expected.   Another
possibility is schedulability.
For example, are all the tasks at the same level of priority?    Have you done
a careful analysis of
the schedulability of the design using RMA tools?    With over 100 tasks, it is
essential that you
examine the schedulability issue using contemporary mathematical tools such as
RMA.

Do not automatically assume you must eliminate tasking from your program.
Properly designed,
tasking can work quite well and give your program a level of robust perfomance
you might not
otherwise be able to easily achieve.  This is especially true of the Ada 95
tasking model.

Richard Riehle

Re: Ada 95 tasking problems with Ada 83 code

[Jeff Creem]

Is it possible that all of the tasks are the same priority and that your
main task
(the one doing the rendevous calls) is never giving back the processor so
that the
other tasks never get to run (on some compilers/environments the run time
would
round robin on a time slice basis between tasks of equal priority). You
can test this by adding delay after you return from calling the tasks entry.

If this is the case, the system is not really well put together. You can
probably
still run with 100 tasks but it will take a little tweaking.

The other option is to try switching task models from FSU threads to Linux
threads.

Finally, if you are not a supported customer of ACT perhaps you should
think about becomming one before you spend a lot of money re-architecting
code
for something that is some simple environment problem. (Note : I am not an
ACT
employee or consultant or anything..I just hate to see people go down a path
of trashing reused code and or compilers when there was some simple fix
available all along)

I can say that in general I have done things like what you are doing many
times
with no problems with GNAT on Linux.

> I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> running Linux.  Creating the executable was not a big problem, but I
> can't get it to run very far.  It appears that when a procedure
rendezvous'
> with a task, the task won't run.  The task has a simple accept statement,
> and it appears to accept the rendezvous because the calling routine
> continues to process.  Text_IO calls before and after the accept statement
> in the task fail to appear on the screen though.  If I put a "do ... end"
> on the accept statement then the caller no longer continues (i.e.
> suspended).
>
> Is this a known problem?  Is there a solution other then removing all
> tasks in our program (over 100).
>

Re: Ada 95 tasking problems with Ada 83 code

[Bill Dale]

Wayne Lydecker wrote:
> 
> I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> running Linux.  

I would recommend a two step process.  First get the code running with 
Gnat Ada95 on the HP-UX system.  This eliminates any Ada95 or Gnat
issues.  
Then port to the PC using Gnat Ada 95.   

Creating the executable was not a big problem, but I
> can't get it to run very far.  It appears that when a procedure rendezvous'
> with a task, the task won't run.  The task has a simple accept statement,
> and it appears to accept the rendezvous because the calling routine
> continues to process.  Text_IO calls before and after the accept statement
> in the task fail to appear on the screen though.  If I put a "do ... end"
> on the accept statement then the caller no longer continues (i.e.
> suspended).
> 

If you are running on Windows any real-time performance is not
predictable.  Windows is not a real-time OS or even close.   

The comments about Rate Monotonic Analysis of your tasking design are
very valid.  
I recommend "Concurrency with Ada" by Weller as a good reference on Ada
95 tasking issues.


> Is this a known problem?  Is there a solution other then removing all
> tasks in our program (over 100).
> 
> Thanks,
> 
> Wayne Lydecker
> wayne@visicom.com


William L. Dale
"If we spend all of our time in ADM's talking about TLA's we'll be SOL!"
Speaking for myself 
Lockheed Martin, Space Systems Company,
Missiles & Space -Sunnyvale Operations
mailto:william.dale.jr@lmco.com

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Bill Dale wrote:

>
>
> The comments about Rate Monotonic Analysis of your tasking design are
> very valid.
> I recommend "Concurrency with Ada" by Weller as a good reference on Ada
> 95 tasking issues.
>

I also recommend a new book by Dan Roy along with a co-author named Loic.
Unfortunately,
my copy of the book is not at this office at the moment.  The book has a title
that reflects its
attention to hard-deadline, real-time software and many of the examples are in
Ada.  Also, they
focus heavily on the scheduling issues addressed by RMA/RMS.   Good theoretical
treatment
with lots of practical examples.

Aha.  Found a bibliographic reference to it:

                           Briand, Lo�c P. and   Roy, Daniel M.,
                           Meeting Deadlines in Hard Real-Time Systems,
                           IEEE Computer Society Press,  ISBN 0-8186-7406-7

Also, anything written by Alan Burns and/or Andy Wellings would be useful.

Richard Riehle

Re: Ada 95 tasking problems with Ada 83 code

[Robert Barron]

>> 
>> > I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
>> > running Linux.  Creating the executable was not a big problem, but I
>> > can't get it to run very far.  It appears that when a procedure rendezvous'
>> > with a task, the task won't run.  The task has a simple accept statement,
>> > and it appears to accept the rendezvous because the calling routine
>> > continues to process.  Text_IO calls before and after the accept statement
>> > in the task fail to appear on the screen though.  If I put a "do ... end"
>> > on the accept statement then the caller no longer continues (i.e.
>> > suspended).
>> >
>> > Is this a known problem?  Is there a solution other then removing all
>> > tasks in our program (over 100).

I'd also look into the differences between multi-cpu HP-UX (Iassume)
and single CPU LINUX 
maybe the run time library can't implement the tasks properly?
try adding pragma TIME_SLICE (which will help the implementation)

worked for me once...

Robert

Re: Ada 95 tasking problems with Ada 83 code

[Wayne Lydecker]

Richard Riehle wrote:
> 
> Wayne Lydecker wrote:
> 
> > I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> > running Linux.  Creating the executable was not a big problem, but I
> > can't get it to run very far.  It appears that when a procedure rendezvous'
> > with a task, the task won't run.  The task has a simple accept statement,
> > and it appears to accept the rendezvous because the calling routine
> > continues to process.  Text_IO calls before and after the accept statement
> > in the task fail to appear on the screen though.  If I put a "do ... end"
> > on the accept statement then the caller no longer continues (i.e.
> > suspended).
> >
> > Is this a known problem?  Is there a solution other then removing all
> > tasks in our program (over 100).
> >
> 
> You mention the calls to Text_IO.  This is a potential source of trouble in
> tasking, especially
> if you have any kind of Get or Get_Line statements.   Recommend looking at
> Get_Immediate,
> and Look_Ahead as possible alternatives to other Get statements.  The standard
> Get statement
> blocks waiting for input but Get_Immediate can get whatever is in the buffer
> without waiting
> for a CR/LF.
><snip>
> Richard Riehle

That's it!  Turns out that the test program that starts the main
program creates a task that displays a menu and then uses a call to
text_io.get_line.  Evidently, the get_line in a task blocks the main
program.

I tried text_io.look_ahead, but end_of_line was always False.  Do
I have to check each character for <CR>?  Text_IO.Get_Immediate
works fine for single characters, but again I would have to search
for <CR>.

Would it work OK to reverse what is going on here and create a new task
to launch the main program and keep the test driver as a procedure?
Would the text_io.get_line still block the main program?

Thanks again Richard, I was about to perform a major re-write.  I
am almost complete with my task ;-)

-- Wayne.

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Wayne Lydecker wrote:

>
>
> That's it!  Turns out that the test program that starts the main
> program creates a task that displays a menu and then uses a call to
> text_io.get_line.  Evidently, the get_line in a task blocks the main
> program.
>
> I tried text_io.look_ahead, but end_of_line was always False.  Do
> I have to check each character for <CR>?  Text_IO.Get_Immediate
> works fine for single characters, but again I would have to search
> for <CR>.
>
> Would it work OK to reverse what is going on here and create a new task
> to launch the main program and keep the test driver as a procedure?
> Would the text_io.get_line still block the main program?
>
> Thanks again Richard, I was about to perform a major re-write.  I
> am almost complete with my task ;-)

Wayne,

It is often the case that the initial Get_Line is associated with an entry call in
an Ada 83
task for task initialization.  For example, the task needs to get its own name or
some other
kind of ID.   This had to be done with an entry call in Ada 83 but can be
accomplished
in Ada 95 more easily and with less overhead.   Simply create a task type with a
discriminant
and decclare or allocate the task with the actual parameter for the discriminant.
If the
information required is a composite type (String or record), simply use a access
discriminant.

This can save some time, eliminate start-up blocking, and is evaluated at
elaboration time
instead of during actual task execution.  That is, there is no blocking and no
context
switching overhead.  This technique becomes especially useful if you are doing
dynamic
allocation of the task at different stages of the life of a program.

Reminder:  you still need to take a look at RMA if you have 100 concurrent tasks.

Richard Riehle
richard@adaworks.com

Re: Ada 95 tasking problems with Ada 83 code

[Robert A Duff]

Wayne Lydecker <wayne@mtws.visicom.com> writes:

> Would it work OK to reverse what is going on here and create a new task
> to launch the main program and keep the test driver as a procedure?
> Would the text_io.get_line still block the main program?

Probably.

- Bob

Re: Ada 95 tasking problems with Ada 83 code

[Jeff Creem]

"Wayne Lydecker" <wayne@mtws.visicom.com> wrote in message
news:39B046AE.A05C82AA@mtws.visicom.com...

Stuff Deleted
> launched the software-to-debug via a task.  The first get_line locks it
> up solid.  I find it hard believe that a get_line blocks all tasks in ada
95
> but not in ada 83, and they provide no simple alternative.  I guess I have
> to write my own get_line that uses get_immediate, which does not block the
> tasks from running.  I wish to thank everyone for all of their wonderful
> comments.  I have successfully proven that our code can be ported to a
> PC running Linux.
>
> -- Wayne.

Actually this is not a difference between Ada 83 and Ada 95 but a difference
between implementations. There are many implementations of Ada 95 on
which Get_Line does not block the entire process. There are also plenty of
Ada 83 environments in which Get_Line (or more often in both cases other
blocking OS calls) blocks the entire process.

It may be allowed by the RM but I would find such an environment too
restrictive
and would not use it for any "real" work. (Ok I can hear the gates opening
from
people who will compain that to write such a program is erroneous or
something.)

I still suspect/hope there is a solution to your problem and again recommend
contacting ACT for support. I have hinted around a potential solution
(mainly because
I did not know the answer off the to of my head. ) But I would recommend
reading
the README.Tasking that comes with GNAT

To save reading the part that I thought might apply is:

"overhead of a context switch between two system threads. However,
it means that you may well lose concurrency at the system
level. Notably, some system operations, such as I/O may block all
tasks in a program, rather than just the calling task. More
significantly, the FSU threads approach likely means you cannot"




Here it is in full:

This README contains information relevant to tasking on the following
systems:
Sparc Solaris, x86 Linux, HP-UX, PowerPC AIX and SGI IRIX.

The 'adainclude' subdirectory containing the sources of the GNAT runtime is
located along with the 'adalib' subdirectory containing the ALI files
and the static and/or shared GNAT library in the gcc target dependent area:
     target=$prefix/lib/gcc-lib/`gcc -dumpmachine`/`gcc -dumpversion`/

On some machines (Solaris Sparc, Linux, HP-UX, AIX), 2 different run times
are
delivered with the standard binary release.

On Solaris, Linux and AIX, the run times are called 'rts-native' and
'rts-fsu'.
On HP-UX, they are called 'rts-dce' and 'rts-pthread'.

rts-native  offers a binding to the native thread package.
rts-fsu     offers a binding to the FSU threads which provide full Annex D
            semantics.
rts-dce     offers a binding to the HP-UX 10.20 DCE thread package.
rts-pthread offers a binding to the HP-UX 11.00 POSIX pthread package. Note
            that this run time will only work with HP-UX 11.00, even if it
is
            always distributed and installed.

Those 2 run times are installed in the target dependant area and contain a
complete source and binary subdirectory. See a detailled description below
to help you choosing between the two different run times.

The default run time (when installing GNAT) is as follows:
rts-native for Solaris and AIX
rts-fsu for Linux
rts-dce for HP-UX

This default run time is selected by the means of soft links. For example on
Solaris and AIX:

 $(target-dir)
     |
     +--- adainclude----------+
     |                        |
     +--- adalib-----------+  |
     |                     |  |
     +--- rts-native       |  |
     |    |                |  |
     |    +--- adainclude <---+
     |    |                |
     |    +--- adalib <----+
     |
     +--- rts-fsu
          |
          +--- adainclude
          |
          +--- adalib


If the other runtime is to be selected on a permanent basis, these soft
links
can be modified with the following commands:

    $ cd $target
    $ rm -f adainclude adalib
    $ ln -s rts-fsu/adainclude adainclude
    $ ln -s rts-fsu/adalib adalib

Alternatively, you can specify 'rts-fsu/adainclude' in the file
$target/ada_source_path and 'rts-fsu/adalib' in $target/ada_object_path.
Please refer to the GNAT User's Guide for more information about these
files.

If the other run time is to be selected temporarily, this can be
achieved by regular GNAT object or source path selection, either by
setting the environment variables:

    $ ADA_INCLUDE_PATH=$target/rts-fsu/adainclude:$ADA_INCLUDE_PATH
    $ ADA_OBJECTS_PATH=$target/rts-fsu/adalib:$ADA_OBJECTS_PATH
    $ export ADA_INCLUDE_PATH ADA_OBJECTS_PATH

or by using -aI$target/rts-fsu/adainclude
        and -aO$target/rts-fsu/adalib
on the gnatmake command line.

You can similarly switch to rts-native on Linux and rts-pthread on HP-UX
11.00.

Choosing between native or FSU threads libraries
------------------------------------------------

Some GNAT implementations offer a choice between two threads
libraries. On Sparc Solaris, Linux and AIX, you can choose to use either:

  o FSU threads

or

  o Native threads

* The native threads correspond to the standard system threads
implementation (e.g. LinuxThreads on Linux, POSIX threads on AIX or
Solaris threads on Solaris). When this option is chosen, GNAT provides
full and accurate implementation of the core language tasking as described
in Chapter 9, but may not (and probably does not) provide
completely accurate implementation of the Annex D (real time)
requirements.  Indeed, the reason that we provide the choice
on a given target is typically that we have found that some of the
ACVC tests for Annex D fail using the native threads. We do try to
map the native threads as well as possible onto Ada requirements,
e.g. modifying priorities as required to simulate ceiling locking,
but there are often slight inaccuracies, most often in the area of
absolute respecting of the priority rules on a single
processor. We can't in general say *exactly* what the semantics
that you will get are, because the native threads implementations
are not well enough documented.

On systems where the SCHED_FIFO POSIX scheduling is supported, native
threads will provide a semantic very close to Annex D requirements
(i.e a run-til-blocked scheduler with fixed priorities), but note that
on some systems (in particular Linux and Solaris), you need to have root
priviledges to use the SCHED_FIFO policy.

* The FSU threads provide a completely accurate implementation of
Annex D requirements, and operating with FSU threads, as far as we
know, GNAT is 100% compliant with both the core and all annex
requirements. The formal validations for implementations offering
a choice of threads packages are always carried out using the FSU
threads option.

From this, it might seem like FSU threads are the better choice,
but that is by no means always the case. The FSU threads package
operates with all Ada tasks appearing to the system to be a single
thread. This is often considerably more efficient than operating
with separate threads, since for example, switching between tasks
can be accomplished without the (in some cases considerable)
overhead of a context switch between two system threads. However,
it means that you may well lose concurrency at the system
level. Notably, some system operations, such as I/O may block all
tasks in a program, rather than just the calling task. More
significantly, the FSU threads approach likely means you cannot
take advantage of multiple processors, since for this you need
separate threads (or even separate processes) to operate on
different processors.

For most standard kinds of processing, the native threads is
usually the better choice. Use the FSU threads if absolute
conformance to annex D is important for your application, or if
you find that the improved efficiency of FSU threads is significant to you.

The default threads on Solaris is currently native Solaris threads.
The default threads on Linux is currently FSU threads.
The default threads on AiX is currently native AiX threads.

Choosing between DCE or POSIX threads libraries on HP-UX 11.00
--------------------------------------------------------------

On HP-UX 11.00, you can choose to use either:

  o DCE threads

or

  o POSIX threads

* The DCE threads correspond to the HP-UX 10.20 user level thread library.
Despite the fact that DCE threads are user level threads library, they
provide thread blocking system calls emulation, but the handling of signals
suffers, however, some limitations.

* The POSIX threads provide a kernel thread library with true thread
blocking
system calls, and better signal handling capabilities. It is however
currently
not possible to use the debugger with an application based on the HP-UX
11.00
pthread run time.

Due to the current debugger limitations and for compatiblity reasons, the
default threads used on HP-UX is DCE threads, but we encourage people to use
the POSIX threads when it is more convenient, since this is the library
of choice for HP.

Solaris threads specific considerations
---------------------------------------

Starting with Solaris 2.5.1 when using the Solaris threads (default)
the default is for programs compiled with GNAT to take advantage of
multiple processors and actually execute on multiple processors.
The user can also specify a processor on which the program should run
on to emulate a single-processor system. This can be easily done by
setting environment variable GNAT_PROCESSOR to one of the following :

    -2 : use the default configuration (run the program on all
         available processors) - this is the same as having
         GNAT_PROCESSOR unset
    -1 : let the RTS choose one processor and run the program on
         that processor
    0 .. Last_Proc : run the program on the specified processor

  Last_Proc is equal to the value of the system variable
  _SC_NPROCESSORS_CONF, minus one.

IRIX threads specific considerations
------------------------------------

On IRIX, the thread library used differs depending on the compiler used:
The o32 ABI compiler comes with a run time based on the user level 'athread'
library. This means that kernel level capabilities such as non blocking
system
calls, time slicing can only be achieved reliably by specifying different
'sprocs' via the pragma Task_Info and the System.Task_Info package. See the
GNAT documentation for more details.

The n32 ABI compiler comes with a run time based on the kernel POSIX
threads,
and thus, does not suffer from the limitations mentioned above.

Re: Ada 95 tasking problems with Ada 83 code

[Pat Rogers]

"Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
news:39AF2DEC.71D8B897@ix.netcom.com...

<snip>

> Reminder:  you still need to take a look at RMA if you have 100
concurrent tasks.

I confess I don't see why.  Surely the number of tasks, by itself,
doesn't require a schedulability analysis.  (There may very well be
deadlines associated, but that hasn't been indicated as far as I
know.)  Absent deadlines, then this is "just" a concurrent program, in
which case the issues are maximizing throughput and ensuring liveness.
Liveness isn't a function of the number of tasks, so I don't see the
connection.

On the other hand, let's say there are deadlines.  In that case, a
static-priority preemptive scheduling scheme may not be the right
approach (e.g., RMA).  Perhaps a dynamic scheme might be best -- say
Earliest Deadline First (which is optimal too).  In other words, it
seems to me that that the info so far -- 100 tasks -- isn't sufficient
to require use of any schedulability analysis, RMA or otherwise.

(Sure, the more tasks one has the more likely a general-purpose
tasking system is to bog down, but that is a separate issue I would
think.)

Of course you know these things, so what am I missing?

---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Wayne Lydecker wrote:

>
> The original developers of our software were task and generic happy (some
> generics are up to three levels deep).  There is no valid reason that it has
> 100 tasks and I'd like to strip it down to a half dozen or so.

Wayne,

Be careful about this kind of decision.   All too often a designer intuits that less
tasks will be more efficient that more.   In fact,  the ideal for a task-based design
on a single processor, is that every task will always be immediately available to
do its work.   This ideal is frequently unachievable, but one can strive for it.

A corollary of the above statement is that most tasks will spend most of their
life waiting for something to do.   Once that something is actually done,  they
will suspend until asked to do it again.   This means that each task should do the
absolute minimum amount of work.   In particular, keep each rendezvous sparse
to prevent blocking other important actions.

It is not unusual, in fine-tuning a task-based design, to increase the number of tasks,
making each one leaner, instead of reducing the number of tasks.

Of course, it is still essential to do the mathematics on this before making such a
decision.
You must consider context-switching time,  priorities, and a whole host of other related

issues before simply changing the number of tasks in the design.  Also, with Ada 95,
many chores previously handed off to an active task can be more efficiently executed
through a protected type.   If you have not looked at protected types, this would be a
good time to do so.  For a good example of a simple protected variable, see Norman
Cohen's book, Ada As A Second Language,  17.4.4., page 831, from McGraw-Hill,
or, even better, get a copy of Concurrency in Ada, by Alan Burns and Andy Wellings.

Hope this helps,

Richard Riehle

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Pat Rogers wrote:

> "Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
> news:39AF2DEC.71D8B897@ix.netcom.com...
>
> <snip>
>
> > Reminder:  you still need to take a look at RMA if you have 100
> concurrent tasks.
>
> I confess I don't see why.  Surely the number of tasks, by itself,
> doesn't require a schedulability analysis.  (There may very well be
> deadlines associated, but that hasn't been indicated as far as I
> know.)  Absent deadlines, then this is "just" a concurrent program, in
> which case the issues are maximizing throughput and ensuring liveness.
> Liveness isn't a function of the number of tasks, so I don't see the
> connection.
>
> On the other hand, let's say there are deadlines.  In that case, a
> static-priority preemptive scheduling scheme may not be the right
> approach (e.g., RMA).  Perhaps a dynamic scheme might be best -- say
> Earliest Deadline First (which is optimal too).  In other words, it
> seems to me that that the info so far -- 100 tasks -- isn't sufficient
> to require use of any schedulability analysis, RMA or otherwise.
>
> (Sure, the more tasks one has the more likely a general-purpose
> tasking system is to bog down, but that is a separate issue I would
> think.)
>
> Of course you know these things, so what am I missing?

Pat,

I am probably just an RMA bigot and believe everyone who is doing anything
with tasking
should have a rudimentary undestanding of it.   Also,  I see RMA as a
larger issue than the
simple static scheduling of its beginnings.   Most treatments of the
subject, including the
Briand and Roy work I cited earlier, do include treatments of both static
and dynamic scheduling.
However, I believe one should understand the static models before moving
on to the
dynamic ones.

As far as liveness and the number of tasks, if there are truly one-hundred
tasks in this design,
it is hard to imagine that they will all be ready to do their work at the
required instant unless
there is some kind of schedulability scheme.   This can be a really simple
scheme or a really
sophisticated one.   The answer to your question is in the last paragraph
of your posting.  When
there a lot of tasks in a design, absent a good scheduling model (dynamic
or static), there is an
increased probability they will "bog down."

The number of tasks may not always be a direct indicator of the need for
schedulability schemes,
but, as you note, as the number of tasks increases, there is a potential
for them to block each other
at inopportune times and bog down the system.    If the tasks are
communicating, this becomes
even more interesting.    If every task is executing at the same
priority,  and there is a lot of
rendezvous occurring,  one can spend many entertaining hours trying to
fine-tune the performance
of the design.

All that being said, we don't know enough details of Wayne's design to
make absolute pronouncements
about how he should proceed, but I think you would agree that anyone
designing a task-based system
ought to have some awareness of the issues related to schedulability.

Richard

Re: Ada 95 tasking problems with Ada 83 code

[Pat Rogers]

"Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
news:39B52DFC.6EF265D3@ix.netcom.com...
>
> Pat Rogers wrote:
>
> > "Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
> > news:39AF2DEC.71D8B897@ix.netcom.com...
> >
> > <snip>
> >
> > > Reminder:  you still need to take a look at RMA if you have 100
> > concurrent tasks.
> >
> > I confess I don't see why.  Surely the number of tasks, by itself,
> > doesn't require a schedulability analysis.  (There may very well
be
> > deadlines associated, but that hasn't been indicated as far as I
> > know.)  Absent deadlines, then this is "just" a concurrent
program, in
> > which case the issues are maximizing throughput and ensuring
liveness.
> > Liveness isn't a function of the number of tasks, so I don't see
the
> > connection.
> >
> > On the other hand, let's say there are deadlines.  In that case, a
> > static-priority preemptive scheduling scheme may not be the right
> > approach (e.g., RMA).  Perhaps a dynamic scheme might be best --
say
> > Earliest Deadline First (which is optimal too).  In other words,
it
> > seems to me that that the info so far -- 100 tasks -- isn't
sufficient
> > to require use of any schedulability analysis, RMA or otherwise.
> >
> > (Sure, the more tasks one has the more likely a general-purpose
> > tasking system is to bog down, but that is a separate issue I
would
> > think.)
> >
> > Of course you know these things, so what am I missing?
>
> Pat,
>
> I am probably just an RMA bigot and believe everyone who is doing
anything
> with tasking should have a rudimentary undestanding of it.   Also,
I see RMA as a
> larger issue than the simple static scheduling of its beginnings.
Most treatments of the
> subject, including the Briand and Roy work I cited earlier, do
include treatments of both static
> and dynamic scheduling. However, I believe one should understand the
static models before moving
> on to the dynamic ones.

I'm influenced by the Real-Time Systems Group at York, where both have
received quite a bit of thought.  :-)
All kidding aside, I find some of the dynamic ones, such as EDF, to be
simpler.

> As far as liveness and the number of tasks, if there are truly
one-hundred tasks in this design,
> it is hard to imagine that they will all be ready to do their work
at the required instant unless
> there is some kind of schedulability scheme.   This can be a really
simple scheme or a really
> sophisticated one.   The answer to your question is in the last
paragraph of your posting.  When
> there a lot of tasks in a design, absent a good scheduling model
(dynamic or static), there is an
> increased probability they will "bog down."

Humm.  Surely liveness is a property independent of the number of
tasks involved.  A "correct" concurrent program should work no matter
how many tasks exist.  The "finite progress assumption" tells use that
all tasks in a correct concurrent program will eventually run.

I think what you're saying is that a large number of interacting tasks
more likely justifies an analysis of the interactions -- a very
reasonable assertion -- such that some idea of the effective
throughput can be determined.  This determination can then be used to
critique the design.  If so, that seems very reasonable.

Perhaps I have a design in the back of my mind that is biasing my
perception of the effect of the number of tasks.  If most of the tasks
are different (i.e. of a different type) then yes, the idea that they
will all be ready to run at a critical instant seems unlikely, and
some idea of the throughput seems worthy of analysis.  On the other
hand, I often like to have pools of tasks, all of the same type, ready
to do the work that becomes available.  In such a case it might not be
unusual for there to be quite a few created, although most might not
be running at any given moment.  As you say, increasing the pool size
can then be a way of increasing throughput.


> The number of tasks may not always be a direct indicator of the need
for
> schedulability schemes, but, as you note, as the number of tasks
increases, there is a potential
> for them to block each other at inopportune times and bog down the
system.    If the tasks are
> communicating, this becomes even more interesting.    If every task
is executing at the same
> priority,  and there is a lot of rendezvous occurring,  one can
spend many entertaining hours trying to
> fine-tune the performance of the design.

In truth I was really just thinking of the fact that most
general-purpose tasking system implemenations use dynamic data
structures whose performance degrade as they grow in length.


>
> All that being said, we don't know enough details of Wayne's design
to
> make absolute pronouncements about how he should proceed, but I
think you would agree that anyone
> designing a task-based system ought to have some awareness of the
issues related to schedulability.

Certainly for a real-time system.  But for "just" a concurrent
program, I think a full schedulability analysis is overkill.

Pat

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Pat Rogers wrote:

> "Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
> news:39B52DFC.6EF265D3@ix.netcom.com...
>
>
> > All that being said, we don't know enough details of Wayne's design
> to
> > make absolute pronouncements about how he should proceed, but I
> think you would agree that anyone
> > designing a task-based system ought to have some awareness of the
> issues related to schedulability.
>
> Certainly for a real-time system.  But for "just" a concurrent
> program, I think a full schedulability analysis is overkill.

OK.  I will agree with that.   We simply had different models immediately
in mind.   The "pool of tasks" design will be different from a real-time
model
where each task performs some unique action, and deadlines and
schedulability
are critical.   Also, we are still not sure  what Wayne is doing, so he
has some
work to do in deciding which approach is more appropriate.   I am sure you

agree, though, that anyone planning a design using concurrent tasks should
have
a little familiarity with the issues related to scheduling, even when
using a pool of
similar tasks, especially if  those tasks are communicating with each
other.

Richard

Richard Riehle
laoxhai@ix.netcom.com

Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle]

Jeff Creem wrote:

> "Wayne Lydecker" <wayne@mtws.visicom.com> wrote in message
> news:39B046AE.A05C82AA@mtws.visicom.com...
>
> Stuff Deleted
> > launched the software-to-debug via a task.  The first get_line locks it
> > up solid.  I find it hard believe that a get_line blocks all tasks in ada
> 95
> > but not in ada 83, and they provide no simple alternative.  I guess I have
> > to write my own get_line that uses get_immediate, which does not block the
> > tasks from running.  I wish to thank everyone for all of their wonderful
> > comments.  I have successfully proven that our code can be ported to a
> > PC running Linux.
> >
> > -- Wayne.
>
> Actually this is not a difference between Ada 83 and Ada 95 but a difference
> between implementations. There are many implementations of Ada 95 on
> which Get_Line does not block the entire process. There are also plenty of
> Ada 83 environments in which Get_Line (or more often in both cases other
> blocking OS calls) blocks the entire process.
>
> It may be allowed by the RM but I would find such an environment too
> restrictive
> and would not use it for any "real" work. (Ok I can hear the gates opening
> from
> people who will compain that to write such a program is erroneous or
> something.)

Jeff,

Your message,  much of which I snipped in this reply, was informative and had an

excellent collection of ideas related to the various operating systems
involved.  I
will save it for my own collection of reminders of stuff to look at when doing
design.

My only concern about the information is that of design for portability.   You
anticipated,
to some extent, that concern by referring the notion of an "erroneous"
program.   Of
course, each environment is different and that is why we cannot really deploy
software
without understanding the vagaries of each platform.   On the other hand,  if  I
do know
that a particular construct may have a blocking protocol on one platform and not
on
another, would it not be wise of me to select the alternative most likely to
give me
a working solution regardless of the underlying operating system protocol?
Granted,
this is not always possible and may sometimes accrue greater overhead.   Perhaps
it
is an overly cautious approach, but then I am also a defensive driver who takes
twice
as long to reach my destination as anyone else (probably a function of my
Old-Order
Amish ancestry).

Richard Riehle
laoxhai@ix.netcom.com

Re: Ada 95 tasking problems with Ada 83 code

[Pat Rogers]

"Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
news:39B542BE.E0AFA887@ix.netcom.com...
>
> Pat Rogers wrote:
>
> > "Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
> > news:39B52DFC.6EF265D3@ix.netcom.com...
> >
> > > All that being said, we don't know enough details of Wayne's
design to
> > > make absolute pronouncements about how he should proceed, but I
> > > think you would agree that anyone designing a task-based system
ought
> > > to have some awareness of the issues related to schedulability.
> >
> > Certainly for a real-time system.  But for "just" a concurrent
> > program, I think a full schedulability analysis is overkill.
>
> OK.  I will agree with that.   We simply had different models
immediately
> in mind.   The "pool of tasks" design will be different from a
real-time model
> where each task performs some unique action, and deadlines and
schedulability
> are critical.   Also, we are still not sure  what Wayne is doing, so
he has some
> work to do in deciding which approach is more appropriate.   I am
sure you
> agree, though, that anyone planning a design using concurrent tasks
should
> have a little familiarity with the issues related to scheduling,
even when
> using a pool of similar tasks, especially if  those tasks are
communicating with each
> other.

Yes, definitely, if by scheduling you mean the issues of deadlock,
indefinite postponement, livelock, and so on -- i.e., what it means
for a concurrent program to be "correct" --  as well as the
ramifications of task interactions (e.g. context switching) on
performance.  Absent deadlines, though, I think those are sufficient
(as if those were simple subjects!).

A pleasure as always,

pat

Re: Ada 95 tasking problems with Ada 83 code

[Ted Dennison]

Richard Riehle wrote:

> Wayne Lydecker wrote:
>
> >
> > The original developers of our software were task and generic happy (some
> > generics are up to three levels deep).  There is no valid reason that it has
> > 100 tasks and I'd like to strip it down to a half dozen or so.
>
> Be careful about this kind of decision.   All too often a designer intuits that less

...

> issues before simply changing the number of tasks in the design.  Also, with Ada 95,
> many chores previously handed off to an active task can be more efficiently executed
> through a protected type.   If you have not looked at protected types, this would be a

That's my experience with Ada83 programs with large numbers of tasks as well. You end up
having to create tons of extra tasks and task types to handle inter-task synchornization
issues. Such issues can typically be handled with protected types now. So he may have some
real success in reducing the amount of tasks just by converting some of them to protected
objects.


--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Ada 95 tasking problems with Ada 83 code

[Wayne Lydecker]

Richard Riehle wrote:
> 
> Wayne Lydecker wrote:
> 
> >
> > The original developers of our software were task and generic happy (some
> > generics are up to three levels deep).  There is no valid reason that it has
> > 100 tasks and I'd like to strip it down to a half dozen or so.
> 
> Wayne,
> 
> Be careful about this kind of decision.   All too often a designer intuits that less
> tasks will be more efficient that more.   In fact,  the ideal for a task-based design
> on a single processor, is that every task will always be immediately available to
> do its work.   This ideal is frequently unachievable, but one can strive for it.
> 
> A corollary of the above statement is that most tasks will spend most of their
> life waiting for something to do.   Once that something is actually done,  they
> will suspend until asked to do it again.   This means that each task should do the
> absolute minimum amount of work.   In particular, keep each rendezvous sparse
> to prevent blocking other important actions.
> 
> It is not unusual, in fine-tuning a task-based design, to increase the number of tasks,
> making each one leaner, instead of reducing the number of tasks.
> 
> Of course, it is still essential to do the mathematics on this before making such a
> decision.
> You must consider context-switching time,  priorities, and a whole host of other related
> 
> issues before simply changing the number of tasks in the design.  Also, with Ada 95,
> many chores previously handed off to an active task can be more efficiently executed
> through a protected type.   If you have not looked at protected types, this would be a
> good time to do so.  For a good example of a simple protected variable, see Norman
> Cohen's book, Ada As A Second Language,  17.4.4., page 831, from McGraw-Hill,
> or, even better, get a copy of Concurrency in Ada, by Alan Burns and Andy Wellings.
> 
> Hope this helps,
> 
> Richard Riehle

That was exactly what I had in mind.  The majority of our tasks (~75)
are used to synchronize access to the databases.  Most of the rest are
for alarm clocks, which were poorly implemented.  I agree 100% that a
good tasking model works fine for 100+ tasks, but when the tasks have
infinite loops with a "delay duration'small" to allow a context switch
for a type of "round robin" scheduling, it's time for a redesign (which
is really what I want to do).

-- Wayne.

Re: Ada 95 tasking problems with Ada 83 code

[Simon Wright]

Wayne Lydecker <wayne@mtws.visicom.com> writes:

> That was exactly what I had in mind.  The majority of our tasks (~75)
> are used to synchronize access to the databases.  Most of the rest are
> for alarm clocks, which were poorly implemented.  I agree 100% that a
> good tasking model works fine for 100+ tasks, but when the tasks have
> infinite loops with a "delay duration'small" to allow a context switch
> for a type of "round robin" scheduling, it's time for a redesign (which
> is really what I want to do).

Good plan! (you may need to look at protected types and semaphores,
mutexes built on them for the synchronisation aspects).

Did you spot Jeff Creem's post about the GNAT tasking implementations
available on Linux? the default (rts-fsu) runs all tasks in the
context of one process -- block one on I/O and you've blocked them
all. Switch to rts-native.