Re: tasking in Ada and Annex D question

[mueller@informatik.hu-berlin.de (Frank Mueller)]

OK as the author of FSU Pthreads and one of the programmers of
the Gnat Runtime Library GNARL, let me add my $0.02 but commenting
on a few statements made in this thread:

>> 1. How could FSU be an Annex D compliant, if one thread
>> will block the other like this? (even though one will
>> expect that doing an IO message will cause a task to
>> yield the CPU).

FSU Pthreads includes rewrites for certain system calls to avoid
blocking the entire process, e.g. read(), write(), accept()
Thus, there is a minimum of thread-only blocking semantics for
the most important I/O calls.

>... The language defines only one dispatching policy,
>FIFO_Within_Priorities; when this policy is in effect, modifications to the
>ready queues occur only as follows ...

POSIX Threads support for validating an Ada95 compiler includes the LRM as
well as the Annexes. The latter include the real-time annex, and here you
need protocols such as priority inheritance and priority ceiling. The real-time
annex also supports an interrupt model tied to UNIX signals. FSU Pthreads supports
both.

FSU Pthreads also uses strict priority scheduling on either a FIFO hand-off
within equal priorities or, alternately, round-robin within equal priority. And
it is preemptive.

FSU Pthreads has (almost) full support for signals following the POSIX standard (it partly
monopolizes IO and ALRM signals).
Linuxthreads does not follow the POSIX standard for signal delivery (a design problem,
not easy to fix) und monopolizes the USR/USR1 signals.

>Neat would however be a mechanism that combines native linuxthreads
>and FSU into a common mechanism. Groups of Ada tasks could be
>assigned to a single linux thread. FSU is used to manage the
>tasks *within* one linuxthread, and the Linux kernel switches
>between these groups of tasks using linuxthreads. Then you can
>fine-tune the performance versus concurrency tradeoffs with a
>few pragmas. I don't think it is urgent, but it would be rather
>neat. Does this sound like a plan for the future to think about?

I agree 100%, I had this in mind for a while. I recently found a
student who will work on this. The idea is to combine FSU Pthreads
(user-level lib) and Linuxthreads (kernel threads) into something
like to two-layer Solaris model (Solaris threads as lib, LWPs in
the kernel). Maybe we can also fix the signal semantics of Linuxthreads
in the course. The goal was to cope without modifications of the 
Linux kernel. Let's see if it can be done since there are some
problems with this.

In any case, I think everybody would like to see the speed of FSU Pthreads
be combined with the support for thread-only blocking calls (to the kernel
and libraries) and, most of all, support for multiprocessors.
-- 
Frank Mueller   E-Mail: mueller@informatik.hu-berlin.de   WWW: http://www.informatik.hu-berlin.de/~mueller