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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1c3d4536a687b7b0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-09-01 18:05:30 PST Path: supernews.google.com!sn-xit-02!sn-east!supernews.com!newspeer.monmouth.com!newshub.northeast.verio.net!verio!cpk-news-hub1.bbnplanet.com!bstnma1-snf1!news.gtei.net!news.mv.net!not-for-mail From: "Jeff Creem" Newsgroups: comp.lang.ada Subject: Re: Ada 95 tasking problems with Ada 83 code Date: Fri, 1 Sep 2000 21:04:57 -0400 Organization: MV Communications, Inc. Message-ID: <8opjh7$77a$1@pyrite.mv.net> References: <39ADAE51.30550667@mtws.visicom.com> <39ADD3A3.381DEF17@ix.netcom.com> <39AF20CE.FDBDFFFE@mtws.visicom.com> <39AF2DEC.71D8B897@ix.netcom.com> <39B046AE.A05C82AA@mtws.visicom.com> NNTP-Posting-Host: bnh-5-16.mv.com X-Trace: pyrite.mv.net 967856487 7402 199.125.98.16 (2 Sep 2000 01:01:27 GMT) X-Complaints-To: abuse@mv.com NNTP-Posting-Date: 2 Sep 2000 01:01:27 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: supernews.google.com comp.lang.ada:469 Date: 2000-09-02T01:01:27+00:00 List-Id: "Wayne Lydecker" 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.