Tasking issues

Tasking issues

[shaunpatterson]

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

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[Simon Wright]

"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.

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[shaunpatterson]

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

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[Jeffrey R. Carter]

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

Re: Tasking issues

[Simon Wright]

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).

Re: Tasking issues

[shaunpatterson]

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

Re: Tasking issues => Book List

[anon]

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
>

Re: Tasking issues

[Simon Wright]

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?).

Re: Tasking issues

[jimmaureenrogers]

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

Re: Tasking issues

[Jeffrey R. Carter]

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

Re: Tasking issues

[Steve]

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
> 

Re: Tasking issues

[anon]

--
-- 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
>

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[anon]

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

Re: Tasking issues

[Jeffrey R. Carter]

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

Re: Tasking issues

[anon]

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!

Re: Tasking issues

[Simon Wright]

*plonk*

Re: Tasking issues

[Markus E.L. 2]

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)

Re: Tasking issues

[Jeffrey R. Carter]

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

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[Larry Kilgallen]

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.

Re: Tasking issues

[Dmitry A. Kazakov]

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

Re: Tasking issues

[Maciej Sobczak]

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/

Re: Tasking issues

[Jeffrey R. Carter]

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