* Tasking issues @ 2007-08-11 17:03 shaunpatterson 2007-08-11 18:42 ` Dmitry A. Kazakov ` (4 more replies) 0 siblings, 5 replies; 27+ messages in thread From: shaunpatterson @ 2007-08-11 17:03 UTC (permalink / raw) I'm having trouble with tasking in Ada. I'm used to working with pthreads in C/C++... and I'm finding tasks to be somewhat different/annoying. My basic problem is I want to have 2 threads in my program. One thread sits in the background and reads in messages, dispatches them, etc and the other thread reads off a queue and sends out messages when they are available. As an analogy, let's assume my background task just got input from the user (simulating the socket read) and the other task just printed out stuff. Something like procedure main is begin task get_name; task print_something; task body get_name is Name : String (1..25); Last : Integer; begin loop Get_Line (Name, Last); end loop; end get_name; task body print_something is begin loop Put_Line ("blah..."); end loop; end print_something; begin --- main loop; null; end loop; end main; Of course, this doesn't work as I'd expect. Is there a way to "timeout" the first get_name thread... so the OS only waits on that thread for a short period of time to allow the other threads to do their business? and then go back to the thread? Thanks -- Shaun ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 17:03 Tasking issues shaunpatterson @ 2007-08-11 18:42 ` Dmitry A. Kazakov 2007-08-12 11:06 ` Simon Wright 2007-08-11 18:51 ` jimmaureenrogers ` (3 subsequent siblings) 4 siblings, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-11 18:42 UTC (permalink / raw) On Sat, 11 Aug 2007 10:03:24 -0700, shaunpatterson@gmail.com wrote: > I'm having trouble with tasking in Ada. I'm used to working with > pthreads in C/C++... and I'm finding tasks to be somewhat different/annoying. > > My basic problem is I want to have 2 threads in my program. Is that a problem? > One thread sits in the background and reads in messages, > dispatches them, etc and the other thread reads off a queue > and sends out messages when they are available. Queue of what? Of messages? > As an analogy, let's assume my background task just got > input from the user (simulating the socket read) and the other > task just printed out stuff. > > Something like > > procedure main is > begin This is an error > task get_name; > task print_something; > > task body get_name is > Name : String (1..25); > Last : Integer; > begin > loop > Get_Line (Name, Last); > end loop; > end get_name; > > task body print_something is > begin > loop > Put_Line ("blah..."); > end loop; > end print_something; > > begin --- main > > loop; This is also an error > null; > end loop; You don't need a loop here. Your program will never end without looping because the tasks do not. > end main; > > Of course, this doesn't work as I'd expect. You didn't say what you expect. > Is there a way to "timeout" the > first get_name thread... so the OS only waits on that thread for a > short period of time to allow the other threads to do their business? and then go > back to the thread? I don't understand, tasks are subject of scheduling and time sharing. They are switched even if they have something to do. If you want to stop print_something when get_name gets an input, you will need some communication between tasks. You can use a protected object for that or rendezvous. For example: with Ada.Text_IO; use Ada.Text_IO; procedure Main is task Get_Name; task Print_Something is entry Got_Name (Name : String); -- Got user input entry Completed; -- Get_Name is done entry Shut_Down; -- On exit end Print_Something; task body Get_Name is Name : String (1..25); Last : Integer; begin loop select Print_Something.Completed; exit; then abort Get_Line (Name, Last); end select; Print_Something.Got_Name (Name (1..Last)); end loop; Put_Line ("Get_Name is down"); end Get_Name; task body Print_Something is begin loop select accept Got_Name (Name : String) do Put_Line ("Here is the name:" & Name); end Got_Name; delay 1.0; -- Just to make it visible among blah's or accept Shut_Down; Put_Line ("Print_Something is going down"); exit; else Put_Line ("blah..."); end select; end loop; accept Completed; Put_Line ("Print_Something is down"); end Print_Something; begin delay 10.0; -- We don't want to have it endlessly Print_Something.Shut_Down; -- Kill them all end Main; Here Get_Name reads user input and then passes it to Print_Something. Print_Something prints either "blah..." or what Get_Name gave it. The affairs are completed when Print_Something receives Shut_Down. It waits a bit until Get_Name tell it that it is finished too. Note that Get_Line in Get_Name is placed in an asynchronous transfer of control select. See ARM 9.7.4. It waits for Print_Something.Completed while reading the line. Then the former triggers, it aborts reading and exits the loop and the task with it. And, well, you don't need main. You can move Get_Name stuff to main. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 18:42 ` Dmitry A. Kazakov @ 2007-08-12 11:06 ` Simon Wright 2007-08-12 12:05 ` Dmitry A. Kazakov [not found] ` <13bulskfjvogv8e@corp.supernews.com> 0 siblings, 2 replies; 27+ messages in thread From: Simon Wright @ 2007-08-12 11:06 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > I don't understand, tasks are subject of scheduling and time > sharing. They are switched even if they have something to do. If you are using an OS with preemptive tasking (eg VxWorks) ready tasks are only switched when preempted by something of higher priority. A task can voluntarily move itself to the back of the ready queue for its priority by "delay 0.0;" (posssibly not RM-mandated behaviour). Other OSs with this behaviour included (last time I had to find out) Solaris for tasks in the RT class and Linux running the program as root. Don't know about Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 11:06 ` Simon Wright @ 2007-08-12 12:05 ` Dmitry A. Kazakov 2007-08-12 17:12 ` shaunpatterson [not found] ` <13bulskfjvogv8e@corp.supernews.com> 1 sibling, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-12 12:05 UTC (permalink / raw) On Sun, 12 Aug 2007 12:06:52 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> I don't understand, tasks are subject of scheduling and time >> sharing. They are switched even if they have something to do. > > If you are using an OS with preemptive tasking (eg VxWorks) ready > tasks are only switched when preempted by something of higher > priority. A task can voluntarily move itself to the back of the ready > queue for its priority by "delay 0.0;" (posssibly not RM-mandated > behaviour). > > Other OSs with this behaviour included (last time I had to find out) > Solaris for tasks in the RT class and Linux running the program as > root. Don't know about Windows. Yes, Windows too has 16 real-time and 16 time sharing priorities. But that's not Ada! (:-)) Ada is pragma Priority and other means to influence tasks scheduling. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 12:05 ` Dmitry A. Kazakov @ 2007-08-12 17:12 ` shaunpatterson 2007-08-12 18:03 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: shaunpatterson @ 2007-08-12 17:12 UTC (permalink / raw) Well, the two tasks are independent. They don't share data so I was hoping I didn't have to communicate between the two threads. I just wanted the two threads to run quitely in the background. However, one thread is reading from sockets... and that thread is preventing the other task from running. I'd have to check, but I was SURE I set the GNAT Sockets to non-blocking... which (I assume) would allow the other thread to run. The socket thread is using streams. It get held up at a Integer'Input (Stream) line. If the sockets were non-blocking the other task should be able to run right? Another option I guess would be to poll the stream and see how much data is in the stream. If there's not enough delay the task? Is it possible to view how much data is there? I hope I'm making sense. Anyway - I'll double check that my sockets are non-blocking tomorrow at work Thanks -- Shaun ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 17:12 ` shaunpatterson @ 2007-08-12 18:03 ` Dmitry A. Kazakov 2007-08-12 22:10 ` Jeffrey R. Carter 2007-08-13 19:54 ` Simon Wright 2 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-12 18:03 UTC (permalink / raw) On Sun, 12 Aug 2007 10:12:09 -0700, shaunpatterson@gmail.com wrote: > I just wanted the two threads to run quitely in the > background. > > However, one thread is reading from sockets... > and that thread is preventing the other task from running. Reading from socket does not block anything, provided that the tasks are mapped to native threads. > I'd have to check, but I was SURE I set the GNAT Sockets to > non-blocking... which (I assume) would allow the other thread > to run. You should check that tasks are mapped to OS threads. AFAIK, this is the default when you are using GNAT. If not, then all tasks are scheduled by Ada RTL from one system thread and consequently I/O would block all of them. See http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gnat_ugn_unw/Choosing-between-Native-and-FSU-Threads-Libraries.html With native threads you can safely do blocking socket I/O without any problems. Otherwise, you should use only asynchronous I/O. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 17:12 ` shaunpatterson 2007-08-12 18:03 ` Dmitry A. Kazakov @ 2007-08-12 22:10 ` Jeffrey R. Carter 2007-08-13 19:54 ` Simon Wright 2 siblings, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2007-08-12 22:10 UTC (permalink / raw) shaunpatterson@gmail.com wrote: > > I'd have to check, but I was SURE I set the GNAT Sockets to > non-blocking... which (I assume) would allow the other thread > to run. For many implementations, setting the sockets to non-blocking is the way to have the task that's reading from the socket monopolize the processor, unless it contains a delay. Setting the sockets to blocking is usually the way to have the task give up the processor. -- Jeff Carter "Sir Lancelot saves Sir Gallahad from almost certain temptation." Monty Python & the Holy Grail 69 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 17:12 ` shaunpatterson 2007-08-12 18:03 ` Dmitry A. Kazakov 2007-08-12 22:10 ` Jeffrey R. Carter @ 2007-08-13 19:54 ` Simon Wright 2007-08-13 22:30 ` shaunpatterson 2 siblings, 1 reply; 27+ messages in thread From: Simon Wright @ 2007-08-13 19:54 UTC (permalink / raw) shaunpatterson@gmail.com writes: > I'd have to check, but I was SURE I set the GNAT Sockets to > non-blocking... which (I assume) would allow the other thread to > run. Do you mean you called GNAT.Sockets.Initialize (Process_Blocking_IO => True)? (it's a lot of work to set a socket non-blocking, I don't think you would easily forget). Not sure this has the effect you want. I would expect a read from a non-blocking socket that didn't have (enough) input to end with an End_Error exception usually .. or a Socket_Error with EWOULDBLOCK .. or, as someone else suggested, to eat CPU. Unless you really need to do otherwise it's easiest to use ordinary (blocking) IO on the sockets, one task to read from each socket. (You could check out GNAT.Sockets' Selector_Type & Socket_Set_Type). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 19:54 ` Simon Wright @ 2007-08-13 22:30 ` shaunpatterson 2007-08-14 7:10 ` Tasking issues => Book List anon 0 siblings, 1 reply; 27+ messages in thread From: shaunpatterson @ 2007-08-13 22:30 UTC (permalink / raw) Okay well it turns out I didn't call GNAT.Sockets.Initialize (true); Adding that fixed all my problems. Anyway. In response to Anon statement: "But shaunpatterson does not want to read a book" I'm not really against getting a good Ada book. Could anyone recommend a good one? I'm using Ada 95. Thanks for the help -- Shaun ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues => Book List 2007-08-13 22:30 ` shaunpatterson @ 2007-08-14 7:10 ` anon 0 siblings, 0 replies; 27+ messages in thread From: anon @ 2007-08-14 7:10 UTC (permalink / raw) For a book that you can download free, there is "The Big Book of Linux Ada Programming" http://www.pegasoft.ca/resources/boblap/book.html It does have both webpage and a downloadable zip html versions Now as for soft/hard bound books, I am not sure I have not keep updated on my "DOD Ada Development Team" and the books they choose to write. In <1187044245.313861.60620@l70g2000hse.googlegroups.com>, shaunpatterson@gmail.com writes: >Okay well it turns out I didn't call > >GNAT.Sockets.Initialize (true); > >Adding that fixed all my problems. Anyway. In >response to Anon statement: > "But shaunpatterson does not want to read a book" > >I'm not really against getting a good Ada book. Could >anyone recommend a good one? I'm using Ada 95. > >Thanks for the help >-- >Shaun > ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <13bulskfjvogv8e@corp.supernews.com>]
* Re: Tasking issues [not found] ` <13bulskfjvogv8e@corp.supernews.com> @ 2007-08-12 20:20 ` Simon Wright 0 siblings, 0 replies; 27+ messages in thread From: Simon Wright @ 2007-08-12 20:20 UTC (permalink / raw) Dennis Lee Bieber <wlfraed@ix.netcom.com> writes: > On Sun, 12 Aug 2007 12:06:52 +0100, Simon Wright > <simon.j.wright@mac.com> declaimed the following in comp.lang.ada: > >> >> If you are using an OS with preemptive tasking (eg VxWorks) ready >> tasks are only switched when preempted by something of higher >> priority. A task can voluntarily move itself to the back of the >> ready queue for its priority by "delay 0.0;" (posssibly not >> RM-mandated behaviour). >> > On most of the OSs I've run under, "something of higher > priority" included the system clock controlling processing time > slices... and any processes in a priority level tended to > round-robin that level... I was only talking about Ada tasks .. the OS will have all sorts of other stuff, as you suggest, but (from the pov of Ada tasks) these 'only' cooperate to provide the environment in which the Ada tasks execute. In VxWorks (where Ada tasks are mapped to VxWorks tasks), there is no involuntary round-robin behaviour. I dare say the Ada RTS could be written to provide round-robin behaviour, but only for Ada tasks (and I for one would find such a scheme perverted; do you really not want to be able to predict how your RT program will behave?). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 17:03 Tasking issues shaunpatterson 2007-08-11 18:42 ` Dmitry A. Kazakov @ 2007-08-11 18:51 ` jimmaureenrogers 2007-08-11 19:08 ` Jeffrey R. Carter ` (2 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: jimmaureenrogers @ 2007-08-11 18:51 UTC (permalink / raw) On Aug 11, 11:03 am, shaunpatter...@gmail.com wrote: > I'm having trouble with tasking in Ada. I'm used to working with > pthreads > in C/C++... and I'm finding tasks to be somewhat different/annoying. > > My basic problem is I want to have 2 threads in my program. > > One thread sits in the background and reads in messages, > dispatches them, etc and the other thread reads off a queue > and sends out messages when they are available. > > As an analogy, let's assume my background task just got > input from the user (simulating the socket read) and the other > task just printed out stuff. You need to communicate between the tasks. Ada provides many ways for tasks to communicate. The easiest to use are task rendezvous and protected objects. The following example demonstrates the use of a protected object: with Ada.Text_Io; with Ada.strings.Unbounded; procedure Coordinate_Tasks is use Ada.Strings.Unbounded; protected Buffer is entry Put(Item : in Unbounded_String); entry Get(Item : out Unbounded_String); private Message : Unbounded_String; Is_New : Boolean := False; end Buffer; protected body Buffer is entry Put(Item : in Unbounded_String) when not Is_New is begin Message := Item; Is_New := True; end Put; entry Get(Item : out Unbounded_String) when Is_New is begin Item := Message; Is_New := False; end Get; end Buffer; task Read_Input; task body Read_Input is Input_Value : String(1..1024); Length : Natural; begin loop Ada.Text_IO.Get_Line(Item => Input_Value, Last => Length); Buffer.Put(To_Unbounded_String(Input_Value(1..Length))); end loop; end Read_Input; task Print_Output; task body Print_Output is Buffered_Value : Unbounded_String; begin loop Buffer.Get(Buffered_Value); Ada.Text_Io.Put_Line(To_String(Buffered_Value)); end loop; end Print_Output; begin null; end Coordinate_Tasks; The next example uses the rendezvous mechanism allowing tasks to communicate directly with each other: with Ada.Text_Io; with Ada.Strings.Unbounded; procedure Task_Coordination_2 is use Ada.Strings.Unbounded; task Read_Input; task Print_Value is entry Put(Item : Unbounded_String); end Print_Value; task body Read_Input is Input_Value : String(1..1024); Length : Natural; begin loop Ada.Text_Io.Get_Line(Item => Input_Value, Last => Length); Print_Value.Put(To_Unbounded_String(Input_Value(1..Length))); end loop; end Read_Input; task body Print_Value is begin loop accept Put(Item : Unbounded_String) do Ada.Text_Io.Put_Line(To_String(Item)); end Put; end loop; end Print_Value; begin null; end Task_Coordination_2; Jim Rogers ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 17:03 Tasking issues shaunpatterson 2007-08-11 18:42 ` Dmitry A. Kazakov 2007-08-11 18:51 ` jimmaureenrogers @ 2007-08-11 19:08 ` Jeffrey R. Carter 2007-08-11 22:31 ` Steve 2007-08-12 9:00 ` anon 4 siblings, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2007-08-11 19:08 UTC (permalink / raw) shaunpatterson@gmail.com wrote: > Of course, this doesn't work as I'd expect. Is there a way to > "timeout" the > first get_name thread... so the OS only waits on that thread for a > short period > of time to allow the other threads to do their business? and then go > back to > the thread? The simple answer to your question is: Yes. Use a delay statement. -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus 54 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 17:03 Tasking issues shaunpatterson ` (2 preceding siblings ...) 2007-08-11 19:08 ` Jeffrey R. Carter @ 2007-08-11 22:31 ` Steve 2007-08-12 9:00 ` anon 4 siblings, 0 replies; 27+ messages in thread From: Steve @ 2007-08-11 22:31 UTC (permalink / raw) Shaun, Take a look at: http://en.wikibooks.org/wiki/Ada_Programming/Tasking There is an example of a Protected_Buffer that is along the lines of what you need. I worked with several other systems using multi-tasking (multi-threading or whatever they decide to call it this year) before learning Ada. At first I found Ada tasking difficult to understand. It turns out Ada tasking is really very simple. Simpler than any other tasking I've used, and I like it a lot more. There are two basic objects assosciated with tasking: task types and protected objects. There are a few constructs that go along with these types "entry", "accept", "select", "delay", "requeue", and "terminate" (I probably missed one or two). Once you understand the basics of what they do, tasking is easy. Regards, Steve (The Duck) <shaunpatterson@gmail.com> wrote in message news:1186851804.567302.223160@q4g2000prc.googlegroups.com... > I'm having trouble with tasking in Ada. I'm used to working with > pthreads > in C/C++... and I'm finding tasks to be somewhat different/annoying. > > My basic problem is I want to have 2 threads in my program. > > One thread sits in the background and reads in messages, > dispatches them, etc and the other thread reads off a queue > and sends out messages when they are available. > > As an analogy, let's assume my background task just got > input from the user (simulating the socket read) and the other > task just printed out stuff. > > Something like > > procedure main is > begin > task get_name; > task print_something; > > task body get_name is > Name : String (1..25); > Last : Integer; > begin > loop > Get_Line (Name, Last); > end loop; > end get_name; > > task body print_something is > begin > loop > Put_Line ("blah..."); > end loop; > end print_something; > > begin --- main > > loop; > null; > end loop; > end main; > > > Of course, this doesn't work as I'd expect. Is there a way to > "timeout" the > first get_name thread... so the OS only waits on that thread for a > short period > of time to allow the other threads to do their business? and then go > back to > the thread? > > Thanks > -- Shaun > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-11 17:03 Tasking issues shaunpatterson ` (3 preceding siblings ...) 2007-08-11 22:31 ` Steve @ 2007-08-12 9:00 ` anon 2007-08-12 9:43 ` Dmitry A. Kazakov ` (2 more replies) 4 siblings, 3 replies; 27+ messages in thread From: anon @ 2007-08-12 9:00 UTC (permalink / raw) -- -- This works and is almost the same code that you used. -- Exceptions to make the program function with the ability -- to stop task. -- -- For help it is better that you write your code -- test with -- gnatmake main.adb -- then for help compile with: -- gnat1 main.adb -gnatl >main.lst -- -- Then copy and paste the main.lst file to your post -- so that we can the compiler errors. Without too -- much editing of the code. -- with Ada.Text_io ; use Ada.Text_io ; procedure main is task get_name; task print_something; continue : boolean := True ; -- task to continue running task body get_name is Name : String ( 1 .. 25 ) ; Last : Integer ; begin loop Get_Line ( Name, Last ) ; -- Set stop flag if Name ( 1 .. 4 ) = "stop" then continue := false ; end if ; delay 0.0 ; end loop ; end get_name ; task body print_something is begin loop Put_Line ( "blah..." ) ; delay 0.0 ; end loop ; end print_something ; begin --- main -- do nothing! while continue loop delay 0.0 ; end loop ; -- abort tasks. But because get_name may be in the process of -- obtaining data from standard_input. it may require a CR/LF -- to be entered to fully abort the 'get_name' task. abort get_name ; Put_Line ( "EOT -- get_name" ) ; abort print_something ; Put_Line ( "EOT -- print_something" ) ; Put_Line ( "EOJ" ) ; end main; In <1186851804.567302.223160@q4g2000prc.googlegroups.com>, shaunpatterson@gmail.com writes: >I'm having trouble with tasking in Ada. I'm used to working with >pthreads >in C/C++... and I'm finding tasks to be somewhat different/annoying. > >My basic problem is I want to have 2 threads in my program. > >One thread sits in the background and reads in messages, >dispatches them, etc and the other thread reads off a queue >and sends out messages when they are available. > >As an analogy, let's assume my background task just got >input from the user (simulating the socket read) and the other >task just printed out stuff. > >Something like > >procedure main is >begin > task get_name; > task print_something; > > task body get_name is > Name : String (1..25); > Last : Integer; > begin > loop > Get_Line (Name, Last); > end loop; > end get_name; > > task body print_something is > begin > loop > Put_Line ("blah..."); > end loop; > end print_something; > >begin --- main > > loop; > null; > end loop; >end main; > > >Of course, this doesn't work as I'd expect. Is there a way to >"timeout" the >first get_name thread... so the OS only waits on that thread for a >short period >of time to allow the other threads to do their business? and then go >back to >the thread? > >Thanks >-- Shaun > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 9:00 ` anon @ 2007-08-12 9:43 ` Dmitry A. Kazakov 2007-08-12 21:39 ` anon 2007-08-12 21:03 ` Maciej Sobczak 2007-08-12 22:07 ` Jeffrey R. Carter 2 siblings, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-12 9:43 UTC (permalink / raw) On Sun, 12 Aug 2007 09:00:27 GMT, anon wrote: > -- abort tasks. But because get_name may be in the process of > -- obtaining data from standard_input. it may require a CR/LF > -- to be entered to fully abort the 'get_name' task. No, it should abort Get_Line immediately. The operations deferring abort are listed in 9.8(5). > abort get_name ; Aborting tasks is a bad idea, almost always. If you have some shared objects which states might be changed outside an abort-deferred operation, then aborting will corrupt them. It is not always possible to do everything from a protected action (which is abort-deferred). Though asynchronous transfer of control is very much like abort, one can limit the scope of what gets aborted. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 9:43 ` Dmitry A. Kazakov @ 2007-08-12 21:39 ` anon 2007-08-12 22:15 ` Jeffrey R. Carter 2007-08-13 9:22 ` Dmitry A. Kazakov 0 siblings, 2 replies; 27+ messages in thread From: anon @ 2007-08-12 21:39 UTC (permalink / raw) First the 'ABORT' statement is a legal statement. Yes, there are better ways to terminate the task, but that would mean a complete overhaul of shaunpatterson's program, which could confuse shaunpatterson. Also any statement that is valid in the language is valid in the code. And the people who say 'ABORT' statement is bad are just like the guys who said that "GOTO" in other languages or Ada's 'LOOP' statement is bad. Since "GOTO' or 'LOOP' statements are a high-level language version of the 'JMP' assembly instruction. That concept that is just stupid, it comes from people who have no idea of how to program. Try and write code without jumping, which means you could never use the 'case', 'delay', 'do', 'else', 'elsif', 'exception', 'exit', 'for, 'goto', 'if', 'loop', 'raise', 'select', 'terminate', 'then', 'until', 'when', while' statements. For jumping you could only use a subroutine call and 'return' statement with no conditional statements or routines allowed. Now, shaunpatterson just wanted some understanding of the difference between C (fork) and ADA (task). For a deeper understanding he should always go to the library or buy an Ada programming book. Or do a google search of Ada tasking example programs. Then type in the examples and compile and run them. As for "Get_Line immediately", thats an error, The Ada code can not force the operating system or keyboard routine to abort. Try reading RM 7.6.1 (23). 23 (20) Abort is deferred during certain operations related to controlled types, as explained in 9.8. Those rules prevent an abort from causing a controlled object to be left in an ill-defined state. Since the keyboard routine in the operating system is one of the following define in RM 9.8 6 a protected action; 11 an assignment operation to an object with a controlled part. or the 'Get_Line' procedure has connect to a secondary task { aka operating system's keyboard routine } and the execution is define in RM 9.8 as 16 the point where the execution initiates the activation of another task; or 17 the end of the activation of a task; where the another task { aka operating system's keyboard routine }. But shaunpatterson does not want to read a book, so my explaination was good enough! Also where is your example of how the code should be written without a complete overhaul of shaunpatterson's program. Only simple additions or ] changes with some comment for him. In <se8lag9odx40$.1ko5kq7eszy2u.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >On Sun, 12 Aug 2007 09:00:27 GMT, anon wrote: > >> -- abort tasks. But because get_name may be in the process of >> -- obtaining data from standard_input. it may require a CR/LF >> -- to be entered to fully abort the 'get_name' task. > >No, it should abort Get_Line immediately. The operations deferring abort >are listed in 9.8(5). > >> abort get_name ; > >Aborting tasks is a bad idea, almost always. If you have some shared >objects which states might be changed outside an abort-deferred operation, >then aborting will corrupt them. It is not always possible to do everything >from a protected action (which is abort-deferred). > >Though asynchronous transfer of control is very much like abort, one can >limit the scope of what gets aborted. > >-- >Regards, >Dmitry A. Kazakov >http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 21:39 ` anon @ 2007-08-12 22:15 ` Jeffrey R. Carter 2007-08-13 9:13 ` anon 2007-08-13 9:22 ` Dmitry A. Kazakov 1 sibling, 1 reply; 27+ messages in thread From: Jeffrey R. Carter @ 2007-08-12 22:15 UTC (permalink / raw) anon wrote: > > As for "Get_Line immediately", thats an error, The Ada code can not > force the operating system or keyboard routine to abort. Try reading > RM 7.6.1 (23). > > 23 (20) Abort is deferred during certain operations related to controlled > types, as explained in 9.8. Those rules prevent an abort from causing a > controlled object to be left in an ill-defined state. There are no controlled objects in your code. > Since the keyboard routine in the operating system is one of the > following define in RM 9.8 > > 6 a protected action; > 11 an assignment operation to an object with a controlled part. > > or the 'Get_Line' procedure has connect to a secondary task { aka > operating system's keyboard routine } and the execution is define in > RM 9.8 as > > 16 the point where the execution initiates the activation of another > task; > or > 17 the end of the activation of a task; > > where the another task { aka operating system's keyboard routine }. There are no protected actions in your code. The only task activations in your code are of the 2 tasks Get_Name and Print_Something. -- Jeff Carter "Sir Lancelot saves Sir Gallahad from almost certain temptation." Monty Python & the Holy Grail 69 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 22:15 ` Jeffrey R. Carter @ 2007-08-13 9:13 ` anon 2007-08-13 19:37 ` Simon Wright 2007-08-14 0:40 ` Jeffrey R. Carter 0 siblings, 2 replies; 27+ messages in thread From: anon @ 2007-08-13 9:13 UTC (permalink / raw) Do You Know anything about programming? TROLL! Or are you just a JOKE {Hint your sig, suggest so} that wishes he was a programmer! You need to go back to school and stop falling asleep in class. Any routine in the kernel such as a keyboard routine is a controlled type. In <hELvi.42933$Xa3.12264@attbi_s22>, "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes: >anon wrote: >> >> As for "Get_Line immediately", thats an error, The Ada code can not >> force the operating system or keyboard routine to abort. Try reading >> RM 7.6.1 (23). >> >> 23 (20) Abort is deferred during certain operations related to controlled >> types, as explained in 9.8. Those rules prevent an abort from causing a >> controlled object to be left in an ill-defined state. > >There are no controlled objects in your code. The Get_Line call executes a protected routine. Before speaking You should know something about what you saying! > >> Since the keyboard routine in the operating system is one of the >> following define in RM 9.8 >> >> 6 a protected action; >> 11 an assignment operation to an object with a controlled part. >> >> or the 'Get_Line' procedure has connect to a secondary task { aka >> operating system's keyboard routine } and the execution is define in >> RM 9.8 as >> >> 16 the point where the execution initiates the activation of another >> task; >> or >> 17 the end of the activation of a task; >> >> where the another task { aka operating system's keyboard routine }. > >There are no protected actions in your code. The only task activations >in your code are of the 2 tasks Get_Name and Print_Something. Can you read I was talking about the Keyboard routine! That's why the comment in {}. Or should I say you need to get your eyes check or recheck. > >-- >Jeff Carter >"Sir Lancelot saves Sir Gallahad from almost certain temptation." >Monty Python & the Holy Grail >69 That States Your Just Another STUPID JOKER! ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 9:13 ` anon @ 2007-08-13 19:37 ` Simon Wright 2007-08-13 20:17 ` Markus E.L. 2 2007-08-14 0:40 ` Jeffrey R. Carter 1 sibling, 1 reply; 27+ messages in thread From: Simon Wright @ 2007-08-13 19:37 UTC (permalink / raw) *plonk* ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 19:37 ` Simon Wright @ 2007-08-13 20:17 ` Markus E.L. 2 0 siblings, 0 replies; 27+ messages in thread From: Markus E.L. 2 @ 2007-08-13 20:17 UTC (permalink / raw) Simon Wright wrote: > *plonk* Don't you consider that a bit harsh? You're missing out all the fun :-). anon@anon.org is a real clown and can be quite entertaining. E.g. at http://www.hostingforum.ca/656771-there-can-only-one-gpl-3.html: | Based on the US and international contract laws. There can only be | one active GPL [...] | It does not matter that FSF states that there can be two GPL versions. [...] | Or that Linus Torvalds states that LINUX will stay under version 2. | What contract LAW states is that all programs that are released | under the GPL after the 29, of June, 2007 will now be under GPL 3, | even if that have not updated the license file. [...] | Actually, the people who release the software can be | sued if they do not update the file. [...] | 1) It like a will, if you rewrite your will the new one is the law. | The old one is no longer valid. [...] | Now from my understand this means that Linus Torvalds must either | accept the GPL 3 or adopt a different license for Linux! From the style (intellectual and otherwise) I suspect it's our anon here. My best bet is, he is either Dan Lyons or this Wallace guy (who tried to sue against the GPL on basis of anti trust law of all things). Or there are more of this kind of jokers around. Anyway: Since he reliably fucks up any argument he tries, he's more an entertainment than a menace. Regards -- Markus (still laughing hard) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 9:13 ` anon 2007-08-13 19:37 ` Simon Wright @ 2007-08-14 0:40 ` Jeffrey R. Carter 1 sibling, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2007-08-14 0:40 UTC (permalink / raw) anon wrote: > Do You Know anything about programming? TROLL! > Or are you just a JOKE {Hint your sig, suggest so} that > wishes he was a programmer! You need to go back to > school and stop falling asleep in class. Well, I've only been doing professional SW development since 1975, and only using Ada since 1984, so no doubt you're right. > Any routine in the kernel such as a keyboard routine is a > controlled type. A controlled type is a type derived from Ada.Finalization.Controlled or Ada.Finalization.Limited_Controlled. There is no way for a routine to be a controlled type. > In <hELvi.42933$Xa3.12264@attbi_s22>, "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org> writes: >> There are no controlled objects in your code. > > The Get_Line call executes a protected routine. Before speaking > You should know something about what you saying! What Get_Line does is implementation dependent. The OP was not speaking of a specific implementation, so it's impossible to say anything about what Get_Line does beyond what is specified in the ARM. A protected operation is not a controlled object. Perhaps you should take your own advice. -- Jeff Carter "My brain hurts!" Monty Python's Flying Circus 21 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 21:39 ` anon 2007-08-12 22:15 ` Jeffrey R. Carter @ 2007-08-13 9:22 ` Dmitry A. Kazakov 2007-08-13 12:41 ` Larry Kilgallen 1 sibling, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-13 9:22 UTC (permalink / raw) On Sun, 12 Aug 2007 21:39:58 GMT, anon wrote: > First the 'ABORT' statement is a legal statement. Yes, there are better > ways to terminate the task, but that would mean a complete overhaul of > shaunpatterson's program, which could confuse shaunpatterson. No, it is using abort, which is confusing in a small illustrative program. There is no need to abort tasks in almost any Ada program. > Also any statement that is valid in the language is valid in the code. And > the people who say 'ABORT' statement is bad are just like the guys who > said that "GOTO" in other languages Ada has goto, see ARM 5.8. > or Ada's 'LOOP' statement is bad. > Since "GOTO' or 'LOOP' statements are a high-level language version of > the 'JMP' assembly instruction. Yes, yes. NASA is training astronauts climbing trees, that makes them closer to the moon. Everything is Turing Complete. Equivalence of programs proves nothing. > As for "Get_Line immediately", thats an error, The Ada code can not > force the operating system or keyboard routine to abort. Of course it can, on most operating systems you can wait for a or-combination of events, you can also close the file handle from outside and that will abort pending I/O etc. It is technically possible, though, AFAIK, RM does not require Get_Line being abortable. Yet it is to expect in a decent implementation. [...] > Also where is your example of how the code should be written without a > complete overhaul of shaunpatterson's program. Only simple additions or ] > changes with some comment for him. You mean your code or one of the OP? Your code can be rewritten without aborts and global variables: with Ada.Characters.Latin_1; use Ada.Characters.Latin_1; with Ada.Text_IO; use Ada.Text_IO; procedure Main is task Get_Name is entry Shut_Down; end Get_Name; task Print_Something is entry Shut_Down; end Print_Something; task body Get_Name is Name : String (1..25); Index : Positive; Got_It : Boolean; begin Get_Line : loop Index := Name'First; loop select accept Shut_Down; exit Get_Line; else Get_Immediate (Name (Index), Got_It); end select; if Got_It then exit when Name (Index) = CR; if Index < Name'Last then Index := Index + 1; end if; end if; end loop; if Index = Name'Last then Put_Line ("Input (truncated):" & Name (1..Index - 1)); else Put_Line ("Input:" & Name (1..Index - 1)); end if; end loop Get_Line; end Get_Name; task body Print_Something is begin loop select accept Shut_Down; exit; else Put_Line ("blah..."); end select; end loop ; end Print_Something; begin delay 1.0; Get_Name.Shut_Down; Print_Something.Shut_Down; end Main; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 9:22 ` Dmitry A. Kazakov @ 2007-08-13 12:41 ` Larry Kilgallen 2007-08-13 13:22 ` Dmitry A. Kazakov 0 siblings, 1 reply; 27+ messages in thread From: Larry Kilgallen @ 2007-08-13 12:41 UTC (permalink / raw) In article <1ilz4m777fqa5.lmji3020dpvu$.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 12 Aug 2007 21:39:58 GMT, anon wrote: >> As for "Get_Line immediately", thats an error, The Ada code can not >> force the operating system or keyboard routine to abort. > > Of course it can, on most operating systems you can wait for a > or-combination of events, you can also close the file handle from outside > and that will abort pending I/O etc. On at least one operating system, one can cancel pending I/O without closing the channel. I don't know whether any particular Ada implementation does that, but current posts in this thread seem to be talking about the Ada language rather than implementation-specific characteristics. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-13 12:41 ` Larry Kilgallen @ 2007-08-13 13:22 ` Dmitry A. Kazakov 0 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2007-08-13 13:22 UTC (permalink / raw) On 13 Aug 2007 07:41:07 -0500, Larry Kilgallen wrote: > In article <1ilz4m777fqa5.lmji3020dpvu$.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> Of course it can, on most operating systems you can wait for a >> or-combination of events, you can also close the file handle from outside >> and that will abort pending I/O etc. > > On at least one operating system, one can cancel pending I/O without > closing the channel. You certainly mean VMS (:-)) Yes, they had it already in RSX-11, and ASTs too... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 9:00 ` anon 2007-08-12 9:43 ` Dmitry A. Kazakov @ 2007-08-12 21:03 ` Maciej Sobczak 2007-08-12 22:07 ` Jeffrey R. Carter 2 siblings, 0 replies; 27+ messages in thread From: Maciej Sobczak @ 2007-08-12 21:03 UTC (permalink / raw) On 12 Sie, 11:00, a...@anon.org (anon) wrote: > -- This works I doubt it. > continue : boolean := True ; -- task to continue running Show me the guarantee that changes of this variable made by one task are visible to another task or even that it's not going to crash in flames. Hint: 9.10/11. > -- do nothing! > > while continue loop > delay 0.0 ; > end loop ; This code does quite a lot, actually (let's put the above issues aside for a moment). In embedded device that runs on a battery this is a very effective way to drain it, fast. -- Maciej Sobczak http://www.msobczak.com/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Tasking issues 2007-08-12 9:00 ` anon 2007-08-12 9:43 ` Dmitry A. Kazakov 2007-08-12 21:03 ` Maciej Sobczak @ 2007-08-12 22:07 ` Jeffrey R. Carter 2 siblings, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2007-08-12 22:07 UTC (permalink / raw) anon wrote: > > continue : boolean := True ; -- task to continue running There's no guarantee that operations on this variable are atomic. You can get into pragma Atomic, bu in general, unprotected variables are not a good way for tasks to communicate. > if Name ( 1 .. 4 ) = "stop" then > continue := false ; > end if ; What happens after the following sequence of inputs: "atopofoldSmokey" "s" ? > -- do nothing! > > while continue loop > delay 0.0 ; > end loop ; > > -- abort tasks. But because get_name may be in the process of > -- obtaining data from standard_input. it may require a CR/LF > -- to be entered to fully abort the 'get_name' task. > > abort get_name ; > Put_Line ( "EOT -- get_name" ) ; > abort print_something ; > Put_Line ( "EOT -- print_something" ) ; > Put_Line ( "EOJ" ) ; This does quite a bit. Have the tasks check for the termination condition themselves, and the main procedure's SOS can be "null;" -- Jeff Carter "Sir Lancelot saves Sir Gallahad from almost certain temptation." Monty Python & the Holy Grail 69 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-08-14 7:10 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-08-11 17:03 Tasking issues shaunpatterson 2007-08-11 18:42 ` Dmitry A. Kazakov 2007-08-12 11:06 ` Simon Wright 2007-08-12 12:05 ` Dmitry A. Kazakov 2007-08-12 17:12 ` shaunpatterson 2007-08-12 18:03 ` Dmitry A. Kazakov 2007-08-12 22:10 ` Jeffrey R. Carter 2007-08-13 19:54 ` Simon Wright 2007-08-13 22:30 ` shaunpatterson 2007-08-14 7:10 ` Tasking issues => Book List anon [not found] ` <13bulskfjvogv8e@corp.supernews.com> 2007-08-12 20:20 ` Tasking issues Simon Wright 2007-08-11 18:51 ` jimmaureenrogers 2007-08-11 19:08 ` Jeffrey R. Carter 2007-08-11 22:31 ` Steve 2007-08-12 9:00 ` anon 2007-08-12 9:43 ` Dmitry A. Kazakov 2007-08-12 21:39 ` anon 2007-08-12 22:15 ` Jeffrey R. Carter 2007-08-13 9:13 ` anon 2007-08-13 19:37 ` Simon Wright 2007-08-13 20:17 ` Markus E.L. 2 2007-08-14 0:40 ` Jeffrey R. Carter 2007-08-13 9:22 ` Dmitry A. Kazakov 2007-08-13 12:41 ` Larry Kilgallen 2007-08-13 13:22 ` Dmitry A. Kazakov 2007-08-12 21:03 ` Maciej Sobczak 2007-08-12 22:07 ` Jeffrey R. Carter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox