* Ada Tasks vs Linux processes @ 2001-04-01 15:27 Frank 2001-04-01 22:32 ` David C. Hoos, Sr. 0 siblings, 1 reply; 11+ messages in thread From: Frank @ 2001-04-01 15:27 UTC (permalink / raw) Hi! I have made a package with a task type, I instanciate this task "as a variable" in a test program. It compiles ok. When I perform "ps -ef" while this program runs, I find three processes named "mytest". I have preconceived idea :-) that I should have only two processes. Have I done something in my code that causes this behaviour, or is this the way it is? I'm using the "select ..or ..or delay n" statement below, and I have choosen to use "delay 0.0" to make the process continue with the business logic below without any waiting for any rendezvous. Does delay 0.0 have a predefined behaviour? Source code supplied below Frank ----------- package PA_TEST is task type TTSK_TEST is entry INIT; entry DO_STUFF; entry DIE; end; end PA_TEST; --------- with TEXT_IO; package body PA_TEST is task body TTSK_TEST is RUNNING : BOOLEAN := FALSE; begin accept INIT do TEXT_IO.PUT_LINE ("TTSK_TEST.INIT"); RUNNING := TRUE; end INIT; while RUNNING loop select accept DO_STUFF do TEXT_IO.PUT_LINE ("TTSK_TEST.DO_STUFF"); end DO_STUFF; or accept DIE do TEXT_IO.PUT_LINE("TTSK_TEST.DIE"); RUNNING := FALSE; end DIE; or delay 0.0; -- In order to "fall through" select statement. end select; -- Business logic -- ----"-------- -- ----"-------- end loop; TEXT_IO.PUT_LINE("PA_TEST(Terminates)"); end; begin TEXT_IO.PUT_LINE("PA_TEST(MAIN)"); end PA_TEST; --------- with PA_TEST, TEXT_IO; procedure MYTEST is A_TASK : PA_TEST.TTSK_TEST; WAIT : STRING(1..1); begin TEXT_IO.PUT_LINE("TEST"); A_TASK.INIT; TEXT_IO.PUT_LINE ("Enter a character and press ENTER, please"); TEXT_IO.GET(WAIT); A_TASK.DIE; end MYTEST; ------- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-01 15:27 Ada Tasks vs Linux processes Frank @ 2001-04-01 22:32 ` David C. Hoos, Sr. 2001-04-02 17:30 ` tmoran 2001-04-02 19:57 ` Frank 0 siblings, 2 replies; 11+ messages in thread From: David C. Hoos, Sr. @ 2001-04-01 22:32 UTC (permalink / raw) The behavior is as expected. The three processes you see are the manager thread, the initial thread (i.e., the main program), and your task object. You will note that the PGIDs for all three processes are identical -- i.e., they are all members of the same shared process group -- in other words, the additional processes are so-called "lightweight" processes, sharing by and large, all of the resources of the parent process. By being distinct OS processes, the scheduling of the tasks is done by the OS instead of the Ada runtime, and one task (process) can block (e.g., waiting for IO) without blocking the others. As far as delay 0.0 is concerned, it should yield the CPU to another task, if there's one ready to run. Generally, though, I use delay Duration'Small instead of delay 0.0; "Frank" <franjoe@frisurf.no> wrote in message news:2OHx6.4154$NR.335287@news3.oke.nextra.no... > Hi! > > I have made a package with a task type, I instanciate this task "as a > variable" in a test program. > It compiles ok. > > When I perform "ps -ef" while this program runs, I find three processes > named "mytest". > > I have preconceived idea :-) that I should have only two processes. Have I > done something in my code that causes this behaviour, or is this the way it > is? > > > I'm using the "select ..or ..or delay n" statement below, and I have choosen > to use "delay 0.0" to make the process continue with the business logic > below without any waiting for any rendezvous. Does delay 0.0 have a > predefined behaviour? > > > Source code supplied below > Frank > > ----------- > package PA_TEST is > > task type TTSK_TEST is > entry INIT; > entry DO_STUFF; > entry DIE; > end; > > end PA_TEST; > --------- > with TEXT_IO; > package body PA_TEST is > > task body TTSK_TEST > is > RUNNING : BOOLEAN := FALSE; > begin > > accept INIT do > TEXT_IO.PUT_LINE ("TTSK_TEST.INIT"); > RUNNING := TRUE; > end INIT; > > while RUNNING loop > select > accept DO_STUFF do > TEXT_IO.PUT_LINE ("TTSK_TEST.DO_STUFF"); > end DO_STUFF; > > or > accept DIE do > TEXT_IO.PUT_LINE("TTSK_TEST.DIE"); > RUNNING := FALSE; > end DIE; > > or > delay 0.0; -- In order to "fall through" select statement. > > end select; > > -- Business logic > -- ----"-------- > -- ----"-------- > > end loop; > > TEXT_IO.PUT_LINE("PA_TEST(Terminates)"); > end; > begin > TEXT_IO.PUT_LINE("PA_TEST(MAIN)"); > end PA_TEST; > --------- > with PA_TEST, TEXT_IO; > procedure MYTEST is > A_TASK : PA_TEST.TTSK_TEST; > WAIT : STRING(1..1); > begin > TEXT_IO.PUT_LINE("TEST"); > > A_TASK.INIT; > > TEXT_IO.PUT_LINE ("Enter a character and press ENTER, please"); > TEXT_IO.GET(WAIT); > > A_TASK.DIE; > > end MYTEST; > ------- > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-01 22:32 ` David C. Hoos, Sr. @ 2001-04-02 17:30 ` tmoran 2001-04-02 18:00 ` Robert A Duff 2001-04-02 22:17 ` Jeffrey Carter 2001-04-02 19:57 ` Frank 1 sibling, 2 replies; 11+ messages in thread From: tmoran @ 2001-04-02 17:30 UTC (permalink / raw) >As far as delay 0.0 is concerned, it should yield the CPU to another >task, if there's one ready to run. Generally, though, I use >delay Duration'Small instead of delay 0.0; LRM D.9(7) says the implementation must document the minimum delay value that actually causes the task to block, while D.9(5) says a delay of zero does not block, but is only "potentially blocking". Even among compilers that don't implement Annex D, delay 0.0 usually does not unnecessarily block, while any positive delay usually blocks for two clock ticks, which on some systems can be a surprisingly long time. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-02 17:30 ` tmoran @ 2001-04-02 18:00 ` Robert A Duff 2001-04-02 18:20 ` Ehud Lamm 2001-04-02 22:17 ` Jeffrey Carter 1 sibling, 1 reply; 11+ messages in thread From: Robert A Duff @ 2001-04-02 18:00 UTC (permalink / raw) tmoran@acm.org writes: > LRM D.9(7) says the implementation must document the minimum delay > value that actually causes the task to block, while D.9(5) says a > delay of zero does not block, but is only "potentially blocking". > Even among compilers that don't implement Annex D, delay 0.0 usually > does not unnecessarily block, while any positive delay usually blocks > for two clock ticks, which on some systems can be a surprisingly long > time. Right, but "delay 0.0;" will cause the task to go to the end of its ready queue, so if there's any other task of the same priority waiting to run, it will run. So "delay 0.0;" does what some systems call "yield". (Assuming Annex D.) - Bob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-02 18:00 ` Robert A Duff @ 2001-04-02 18:20 ` Ehud Lamm 0 siblings, 0 replies; 11+ messages in thread From: Ehud Lamm @ 2001-04-02 18:20 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 529 bytes --] > Right, but "delay 0.0;" will cause the task to go to the end of its > ready queue, so if there's any other task of the same priority waiting > to run, it will run. So "delay 0.0;" does what some systems call > "yield". (Assuming Annex D.) > To quote the LRM: The execution time of a delay_statement that does not cause the task to be blocked (e.g. �delay 0.0;� ) is of interest in situations where delays are used to achieve voluntary round-robin task dispatching among equal-priority tasks. (D.9 (14)) Ehud Lamm ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-02 17:30 ` tmoran 2001-04-02 18:00 ` Robert A Duff @ 2001-04-02 22:17 ` Jeffrey Carter 2001-04-04 16:36 ` tmoran 1 sibling, 1 reply; 11+ messages in thread From: Jeffrey Carter @ 2001-04-02 22:17 UTC (permalink / raw) tmoran@acm.org wrote: > > >As far as delay 0.0 is concerned, it should yield the CPU to another > >task, if there's one ready to run. Generally, though, I use > >delay Duration'Small instead of delay 0.0; > LRM D.9(7) says the implementation must document the minimum delay > value that actually causes the task to block, while D.9(5) says a > delay of zero does not block, but is only "potentially blocking". > Even among compilers that don't implement Annex D, delay 0.0 usually > does not unnecessarily block, while any positive delay usually blocks > for two clock ticks, which on some systems can be a surprisingly long > time. Indeed. The Verdix compiler for SCO UNIX responded to "delay Duration'Small;" by delaying until the next clock tick. Since the clock ticked at 1 Hz, this corresponded to an average delay of 0.5 seconds. I saw some very slow code that resulted from the GRACE components using "delay Duration'Small;" to obtain a unique timestamp. Jeffrey Carter ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-02 22:17 ` Jeffrey Carter @ 2001-04-04 16:36 ` tmoran 2001-04-04 17:18 ` Gary Scott 0 siblings, 1 reply; 11+ messages in thread From: tmoran @ 2001-04-04 16:36 UTC (permalink / raw) > ... by delaying until the next clock tick. Note this is a change from Ada 83, where the delay had to be "at least" that specified. Suppose there's a piece of hardware that needs 500 mics to settle after some operation, before it can next be accessed. Given a Duration'small of 10*mics, the unsuspecting programmer might write "delay 500*mics;". With a System.Tick of 1000 mics, that would delay somewhere between 1 and 2 ms, a safe time for the hardware to settle down, when compiled with Ada 83. In Ada 95 it need only take a single tick, which might happen within a few mics of reaching the "delay" statement and thus long before the hardware is ready. Crash and burn. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-04 16:36 ` tmoran @ 2001-04-04 17:18 ` Gary Scott 2001-04-04 19:18 ` tmoran 0 siblings, 1 reply; 11+ messages in thread From: Gary Scott @ 2001-04-04 17:18 UTC (permalink / raw) A more fundamental issue would be why would hardware be designed that did not provide a positive status indication that it was "ready" for further access. Using delays to handle interface issues with slow, poorly designed hardware has caused a huge number of anomalies in avionic systems that I've dealt with over the last 20 years. It's really tiring... tmoran@acm.org wrote: > > > ... by delaying until the next clock tick. > Note this is a change from Ada 83, where the delay had to be "at > least" that specified. Suppose there's a piece of hardware that > needs 500 mics to settle after some operation, before it can next > be accessed. Given a Duration'small of 10*mics, the unsuspecting > programmer might write "delay 500*mics;". With a System.Tick of > 1000 mics, that would delay somewhere between 1 and 2 ms, a safe > time for the hardware to settle down, when compiled with Ada 83. > In Ada 95 it need only take a single tick, which might happen > within a few mics of reaching the "delay" statement and thus long > before the hardware is ready. Crash and burn. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-04 17:18 ` Gary Scott @ 2001-04-04 19:18 ` tmoran 0 siblings, 0 replies; 11+ messages in thread From: tmoran @ 2001-04-04 19:18 UTC (permalink / raw) >A more fundamental issue would be why would hardware be designed that... You will have to ask the hardware guys. I presume the answer has to do with cheapness. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-01 22:32 ` David C. Hoos, Sr. 2001-04-02 17:30 ` tmoran @ 2001-04-02 19:57 ` Frank 2001-04-03 11:28 ` Matthias Kretschmer 1 sibling, 1 reply; 11+ messages in thread From: Frank @ 2001-04-02 19:57 UTC (permalink / raw) Hi! It seems to me (after some more searching in select -statement variations) that the I should use the construction select...or.._else_ to achieve what I intended. But this disussion brings another question to my mind; from some e-threads I read here I have got the impression that I _have_ to perform delay n; in the code so that all tasks get a slice of the execution (perhaps this goes for OS or CPU that does not handle HW multitasking or something?) Is this a true, or can I assume that Ada (and/or the OS it is running in) slices executions on every platform it is implemented? I can understand that a delay n; makes good sense if a task does not have to execute continously and a delay therefore can give execution slices to other tasks instead. Frank ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Ada Tasks vs Linux processes 2001-04-02 19:57 ` Frank @ 2001-04-03 11:28 ` Matthias Kretschmer 0 siblings, 0 replies; 11+ messages in thread From: Matthias Kretschmer @ 2001-04-03 11:28 UTC (permalink / raw) Frank wrote: > Hi! > > It seems to me (after some more searching in select -statement variations) > that the I should use the construction select...or.._else_ to achieve what I > intended. > > But this disussion brings another question to my mind; from some e-threads I > read here I have got the impression that I _have_ to perform delay n; in the > code so that all tasks get a slice of the execution (perhaps this goes for > OS or CPU that does not handle HW multitasking or something?) Is this a > true, or can I assume that Ada (and/or the OS it is running in) slices > executions on every platform it is implemented? > I can understand that a delay n; makes good sense if a task does not have to > execute continously and a delay therefore can give execution slices to other > tasks instead. > It is true, that on systems which do not support preemptive multitasking or on which you ada-compiler doesn't support this, you need delay statements to switch between threads. (e.g. the gnat on FreeBSD (from ports-collection 4.2-stable) doesn't support the os-implementation of threads and simulates non-preemptive - without delay statements on this system with this compiler your active thread won't change) > > Frank ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-04-04 19:18 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-01 15:27 Ada Tasks vs Linux processes Frank 2001-04-01 22:32 ` David C. Hoos, Sr. 2001-04-02 17:30 ` tmoran 2001-04-02 18:00 ` Robert A Duff 2001-04-02 18:20 ` Ehud Lamm 2001-04-02 22:17 ` Jeffrey Carter 2001-04-04 16:36 ` tmoran 2001-04-04 17:18 ` Gary Scott 2001-04-04 19:18 ` tmoran 2001-04-02 19:57 ` Frank 2001-04-03 11:28 ` Matthias Kretschmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox