Re: Timeouts in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 16 Jul 2014 22:18:18 -0700 (PDT), NiGHTS wrote:

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

This is a timed entry call. The callee must be a task's or a protected
object's entry.

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

No. You have a task already. (Usually tasks are mapped to OS threads.)

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

They are visible for the single execution thread along either execution
path. There *no* concurrently executed code here.
 
> 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.

Could be. But it also can be a protected object Password_Server used to
communicate between the task and an I/O worker task or tasks. The protected
object may run state transitions such that Set:

1. Stores the user and the password within the Password_Server;
2. Opens the entry Have_New_Password for a worker task,
3. Requeues Set to the entry Complete_Password_Setting;
4. A worker task blocked on Have_New_Password is released;
5. The worker task sets the password;
6. The worker task Opens Complete_Password_Setting;
7. The caller's task is released, the password is set.

Requeueing a call to another entry you can choose between "requeue" and
"requeue with abort." The latter would allow the delay alternative to
trigger.

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

The callee is not terminated, rather the request is canceled (dequeued from
the entry waiting list).

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

No. They are never executed concurrently. You have either one or another
execution path. It is like:

   if Set-is-through then
      Put_Line ("Done");
   else 
      Put_Line ("The system is busy now, please try again later.");
   end if;

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

Timed entry call does not terminate anything. Networking operations if any
run in another task.

You should consider entry calls as synchronization primitives. By
themselves they are neither concurrent nor parallel.

(Terminating are task abort and asynchronous control transfer.

    select
       delay Timeout;
    then abort
       Password_Server.Set (User, Password);
    end select;

Never use them unless you know what you are doing. The language defines the
way and what can be aborted. This does not work how you would expect it in
most cases. And it certainly does not work in the cases you liked to use
it, e.g. for aborting pending blocking I/O. Ada has no way to do this. The
only things you could safely abort are like some lengthy calculations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de