Re: Ada 95 tasking problems with Ada 83 code

["Jeff Creem" <jcreem@atetola.mv.com>]

"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.