* Ada 95 tasking problems with Ada 83 code @ 2000-08-30 0:00 Wayne Lydecker 2000-08-30 0:00 ` Richard Riehle 2000-08-31 16:00 ` Bill Dale 0 siblings, 2 replies; 21+ messages in thread From: Wayne Lydecker @ 2000-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 Ada 95 tasking problems with Ada 83 code Wayne Lydecker @ 2000-08-30 0:00 ` Richard Riehle 2000-08-30 0:00 ` Wayne Lydecker 2000-09-01 3:21 ` Wayne Lydecker 2000-08-31 16:00 ` Bill Dale 1 sibling, 2 replies; 21+ messages in thread From: Richard Riehle @ 2000-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 ` Richard Riehle @ 2000-08-30 0:00 ` Wayne Lydecker 2000-08-31 0:00 ` Jeff Creem 2000-08-31 20:07 ` Robert Barron 2000-09-01 3:21 ` Wayne Lydecker 1 sibling, 2 replies; 21+ messages in thread From: Wayne Lydecker @ 2000-08-30 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 ` Wayne Lydecker @ 2000-08-31 0:00 ` Jeff Creem 2000-08-31 20:07 ` Robert Barron 1 sibling, 0 replies; 21+ messages in thread From: Jeff Creem @ 2000-08-31 0:00 UTC (permalink / raw) 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). > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 ` Wayne Lydecker 2000-08-31 0:00 ` Jeff Creem @ 2000-08-31 20:07 ` Robert Barron 1 sibling, 0 replies; 21+ messages in thread From: Robert Barron @ 2000-08-31 20:07 UTC (permalink / raw) >> >> > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 ` Richard Riehle 2000-08-30 0:00 ` Wayne Lydecker @ 2000-09-01 3:21 ` Wayne Lydecker 2000-09-01 4:17 ` Richard Riehle 2000-09-01 20:01 ` Robert A Duff 1 sibling, 2 replies; 21+ messages in thread From: Wayne Lydecker @ 2000-09-01 3:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-01 3:21 ` Wayne Lydecker @ 2000-09-01 4:17 ` Richard Riehle [not found] ` <39B046AE.A05C82AA@mtws.visicom.com> 2000-09-02 22:54 ` Pat Rogers 2000-09-01 20:01 ` Robert A Duff 1 sibling, 2 replies; 21+ messages in thread From: Richard Riehle @ 2000-09-01 4:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <39B046AE.A05C82AA@mtws.visicom.com>]
* Re: Ada 95 tasking problems with Ada 83 code [not found] ` <39B046AE.A05C82AA@mtws.visicom.com> @ 2000-09-02 1:04 ` Jeff Creem 2000-09-05 19:11 ` Richard Riehle 2000-09-05 17:12 ` Richard Riehle 1 sibling, 1 reply; 21+ messages in thread From: Jeff Creem @ 2000-09-02 1:04 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-02 1:04 ` Jeff Creem @ 2000-09-05 19:11 ` Richard Riehle 0 siblings, 0 replies; 21+ messages in thread From: Richard Riehle @ 2000-09-05 19:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code [not found] ` <39B046AE.A05C82AA@mtws.visicom.com> 2000-09-02 1:04 ` Jeff Creem @ 2000-09-05 17:12 ` Richard Riehle 2000-09-06 0:19 ` Ted Dennison 2000-09-06 2:38 ` Wayne Lydecker 1 sibling, 2 replies; 21+ messages in thread From: Richard Riehle @ 2000-09-05 17:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-05 17:12 ` Richard Riehle @ 2000-09-06 0:19 ` Ted Dennison 2000-09-06 2:38 ` Wayne Lydecker 1 sibling, 0 replies; 21+ messages in thread From: Ted Dennison @ 2000-09-06 0:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-05 17:12 ` Richard Riehle 2000-09-06 0:19 ` Ted Dennison @ 2000-09-06 2:38 ` Wayne Lydecker 2000-09-07 5:35 ` Simon Wright 1 sibling, 1 reply; 21+ messages in thread From: Wayne Lydecker @ 2000-09-06 2:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-06 2:38 ` Wayne Lydecker @ 2000-09-07 5:35 ` Simon Wright 0 siblings, 0 replies; 21+ messages in thread From: Simon Wright @ 2000-09-07 5:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-01 4:17 ` Richard Riehle [not found] ` <39B046AE.A05C82AA@mtws.visicom.com> @ 2000-09-02 22:54 ` Pat Rogers 2000-09-05 17:31 ` Richard Riehle 1 sibling, 1 reply; 21+ messages in thread From: Pat Rogers @ 2000-09-02 22:54 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-02 22:54 ` Pat Rogers @ 2000-09-05 17:31 ` Richard Riehle 2000-09-05 18:51 ` Pat Rogers 0 siblings, 1 reply; 21+ messages in thread From: Richard Riehle @ 2000-09-05 17:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-05 17:31 ` Richard Riehle @ 2000-09-05 18:51 ` Pat Rogers 2000-09-05 19:00 ` Richard Riehle 0 siblings, 1 reply; 21+ messages in thread From: Pat Rogers @ 2000-09-05 18:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-05 18:51 ` Pat Rogers @ 2000-09-05 19:00 ` Richard Riehle 2000-09-05 19:33 ` Pat Rogers 0 siblings, 1 reply; 21+ messages in thread From: Richard Riehle @ 2000-09-05 19:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-05 19:00 ` Richard Riehle @ 2000-09-05 19:33 ` Pat Rogers 0 siblings, 0 replies; 21+ messages in thread From: Pat Rogers @ 2000-09-05 19:33 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-09-01 3:21 ` Wayne Lydecker 2000-09-01 4:17 ` Richard Riehle @ 2000-09-01 20:01 ` Robert A Duff 1 sibling, 0 replies; 21+ messages in thread From: Robert A Duff @ 2000-09-01 20:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-30 0:00 Ada 95 tasking problems with Ada 83 code Wayne Lydecker 2000-08-30 0:00 ` Richard Riehle @ 2000-08-31 16:00 ` Bill Dale 2000-08-31 17:57 ` Richard Riehle 1 sibling, 1 reply; 21+ messages in thread From: Bill Dale @ 2000-08-31 16:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ada 95 tasking problems with Ada 83 code 2000-08-31 16:00 ` Bill Dale @ 2000-08-31 17:57 ` Richard Riehle 0 siblings, 0 replies; 21+ messages in thread From: Richard Riehle @ 2000-08-31 17:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2000-09-07 5:35 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-08-30 0:00 Ada 95 tasking problems with Ada 83 code Wayne Lydecker 2000-08-30 0:00 ` Richard Riehle 2000-08-30 0:00 ` Wayne Lydecker 2000-08-31 0:00 ` Jeff Creem 2000-08-31 20:07 ` Robert Barron 2000-09-01 3:21 ` Wayne Lydecker 2000-09-01 4:17 ` Richard Riehle [not found] ` <39B046AE.A05C82AA@mtws.visicom.com> 2000-09-02 1:04 ` Jeff Creem 2000-09-05 19:11 ` Richard Riehle 2000-09-05 17:12 ` Richard Riehle 2000-09-06 0:19 ` Ted Dennison 2000-09-06 2:38 ` Wayne Lydecker 2000-09-07 5:35 ` Simon Wright 2000-09-02 22:54 ` Pat Rogers 2000-09-05 17:31 ` Richard Riehle 2000-09-05 18:51 ` Pat Rogers 2000-09-05 19:00 ` Richard Riehle 2000-09-05 19:33 ` Pat Rogers 2000-09-01 20:01 ` Robert A Duff 2000-08-31 16:00 ` Bill Dale 2000-08-31 17:57 ` Richard Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox