From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5f0b2f174ad085de X-Google-Attributes: gid103376,public From: mueller@informatik.hu-berlin.de (Frank Mueller) Subject: Re: tasking in Ada and Annex D question Date: 1999/02/03 Message-ID: <7991mr$mig$1@hahn.informatik.hu-berlin.de>#1/1 X-Deja-AN: 440110016 References: <793jl9$hf@drn.newsguy.com> <7963h1$a6h$1@nnrp1.dejanews.com> <797hoc$j3v$1@nnrp1.dejanews.com> <798u7r$b2k$2@plug.news.pipex.net> Organization: Humboldt-Universitaet zu Berlin Newsgroups: comp.lang.ada Originator: mueller@eiche Date: 1999-02-03T00:00:00+00:00 List-Id: 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