Re: Timeouts in Ada

[Adam Beneschan <adambeneschan@gmail.com>]

On Wednesday, July 16, 2014 10:18:18 PM UTC-7, NiGHTS wrote:
> First of all I just want to say how much I appreciate the help you have given me so far with the questions I have had.
> 
> For this next question I am interested in creating a "wrapper" around certain tasks that should have a timeout period. I feel this feature is part of what makes Ada so good at keeping a software running stable. There are plenty of network and I/O tasks that I would love to have a "fallback" plan in the event that they take too long to execute. 
> 
> For study on this subject I am using this as a reference:
> 
> http://en.wikibooks.org/wiki/Ada_Programming/Tasking#Timeout
> 
> I am looking at Ex. 10. 
> 
>   task Password_Server is
>      entry Check (User, Pass : in String; Valid : out Boolean);
>      entry Set (User, Pass : in  String);
>   end Password_Server;
>   ...
>   User_Name, Password : String (1 .. 8);
>   ...
>   Put ("Please give your new password:");
>   Get_Line (Password);
>   select
>      Password_Server.Set (User_Name, Password);
>      Put_Line ("Done");
>   or
>      delay 10.0;
>      Put_Line ("The system is busy now, please try again later.");
>   end select;
> 
> Now as an Ada beginner with a strong background in C/Asm I interpret this example in the following way...
> 
> 1. "select" creates a thread which runs the body of "select" or the body of "or". Or maybe it creates two threads for each and blocks its own thread until one finishes.

I think the mistake you're making is treating the two sequences of statements 

     Password_Server.Set (User_Name, Password);
     Put_Line ("Done");

and 

     delay 10.0;
     Put_Line ("The system is busy now, please try again later.");

as independent "bodies".

That's not how SELECT works.  The first statement following SELECT is treated specially.  It is restricted; it can only be an entry call, an ACCEPT, or a DELAY (the DELAY is possible only if there's a "THEN ABORT" part).  The first statement following OR is also restricted, and is treated specially; if you're selecting on an entry call, it *must* be a DELAY.

So instead of looking at this as two separate blocks of code and trying to figure out how the task executes those two blocks, you need to look at those first statements to see what the SELECT's purpose is.  And when you have SELECT <entry-call> ... OR DELAY 10.0, it means that the task waits until the entry is available, but it only waits 10 seconds and then gives up.  And then, depending on whether the entry call timed out or not, it executes one or the other of the statements that *follow* the first statement.  This doesn't require separate threads trying to execute both blocks.  

Look at it more like this [this is not real Ada code, of course]:

    if Try_Entry_Call (Password_Server.Set (User_Name, Password), Timeout => 10.0) = ACCEPTED then
         Wait_For_Rendezvous_To_Complete;
         Put_Line("Done");
    else
         Put_Line("The system is busy now, please try again later."); 
    end if;

If the first statement after SELECT is an ACCEPT or DELAY, or if there's a THEN ABORT clause, the statement will have different semantics, and it won't look like the IF statement I wrote above.  There are four different kinds of SELECT.

                               -- Adam





> 
> 2. In either case the variables in scope where "select" was run will be accessible to both the thread created to deal with the body of "select" and the body of "or"
> 
> 
> 
> 3. The "Password_Server" task is run in its very own thread so it has its own internal scope of variables. So this would mean that the "select" body is dealing with two nested threads.
> 
> 
> 
> 4. If the "select" body completes before the "or" body is completed, the "or" thread is terminated. If the "or" body completes before the "select" body completes, the "select" body and the Password_Server (if applicable) is terminated.
> 
> 
> 
> 5.a. If both threads happen to reach the "Put_Line" command of each body, both threads will terminate and there would be a conflict of information -- It will confuse the user with printing both "Done" AND "The system is busy". If this was a more mission-critical operation, both the main operation and its fallback plan may execute at the same time. In other words I don't see how this is atomic, and if its not atomic how could this possibly be useful to anyone?
> 
> 
> 
> 5.b. Terminating threads while its doing things (while writing to shared memory? performing network operations mid-way?) sounds disastrous, but it seems like the only way this could possibly function in Ada.
> 
> 
> 
> Now keep in mind these are all assumptions I made in order to make sense of what I am reading. So far in my self-study of Ada 80% of everything had to be assumed with the help of trial and error because no literature that I have read explained WHY things happen, only superficial usage syntax. Its rather annoying but that is why I am so thrilled to be able to ask this question here.
> 
> 
> 
> Thank you again for all your help!