Timeouts in Ada

Timeouts in Ada

[NiGHTS]

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.

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!

Re: Timeouts in Ada

[Simon Wright]

NiGHTS <nights@unku.us> writes:

> 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, there are probably only 2 threads here; the one running the code
that executes the select, and the server task.

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

I don't see why the server task would be 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?

There will be some complicated arrangment of condition variables (Unix),
semaphores (VxWorks), or other OS-dependent mechanisms to ensure that
the select statement runs as  required.

cond_timedwait(3) example from [1] - not very clear really, I admit:

       The cond_timedwait() function is normally used in a loop testing
       some condition.  It uses an absolute timeout value as follows:

	 timestruc_t to;
	 ...
	 (void) mutex_lock(mp);
	 to.tv_sec = time(NULL) + TIMEOUT;
	 to.tv_nsec = 0;
	 while (cond == FALSE) {
	       err = cond_timedwait(cvp, mp, &to);
	       if (err == ETIME) {
		     /* timeout, do something */
		     break;
	       }
	 }
	 (void) mutex_unlock(mp);

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

You're actually asking HOW the compiler does it; ARM 9.7.1(15ff)[2] says
WHAT the compiler has to arrange to happen to meet the standard.

[1] http://www.unix.com/man-page/opensolaris/3c/cond_wait/
[2] http://www.ada-auth.org/standards/12rm/html/RM-9-7-1.html#p15

Re: Timeouts in Ada

[J-P. Rosen]

Le 17/07/2014 07:18, NiGHTS a écrit :
> 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.
> 
[Rest snipped, since based on wrong assertion]

Not at all! In Ada, one task=one thread, there are no hidden threads.

This kind of select is called a timed entry call. It tries to rendezvous
with Password_Server; if the server accepts the rendezvous before 10.0
seconds, the statements after the entry call are executed and the "or"
part is ignored. If the server doesn't accept the rendezvous within 10.0
seconds, the rendezvous request is cancelled and the statements in the
"or" part are executed.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Timeouts in Ada

[Dmitry A. Kazakov]

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

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 3:08:47 AM UTC-4, Simon Wright wrote:
> 
> You're actually asking HOW the compiler does it; ARM 9.7.1(15ff)[2] says
> 
> WHAT the compiler has to arrange to happen to meet the standard.
> 
> [1] http://www.unix.com/man-page/opensolaris/3c/cond_wait/
> 
> [2] http://www.ada-auth.org/standards/12rm/html/RM-9-7-1.html#p15

These links were very helpful. I had almost forgotten about the ARM when faced with this question. Also, the C explanation makes sense to me -- I suppose the Ada select/or/else is a kind of lexical adaptation of cond_timedwait() and family. I personally just mutex locked shared resources in my C code so I was not aware of this technique.

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 3:38:40 AM UTC-4, J-P. Rosen wrote:
> 
> This kind of select is called a timed entry call. It tries to rendezvous
> 
> with Password_Server; if the server accepts the rendezvous before 10.0
> 
> seconds, the statements after the entry call are executed and the "or"
> 
> part is ignored. If the server doesn't accept the rendezvous within 10.0
> 
> seconds, the rendezvous request is cancelled and the statements in the
> 
> "or" part are executed.
> 

I was mainly confused by the fact that the delay command was placed inside the body of a fork in the path of logic, making it seem as though in order to satisfy the syntax it had to do things concurrently. ARM seems to imply that it expects a delay in the body (first command?) as a condition to determine which path to take. I'm still a little fuzzy on the mechanics but I'm sure this will clear up as I do some more reading on the C variant.

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 3:42:21 AM UTC-4, Dmitry A. Kazakov wrote:
> 
> This is a timed entry call. The callee must be a task's or a protected
> 
> object's entry.
> 

Are you suggesting that the select/or would not work inside the main procedure? I haven't tried this yet so I don't know yet if this is valid or not.


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

I would never use something I don't understand. This is precisely why I asked this kind of question.


Say I had a subroutine which submits a query to a database in a non-blocking way. Thus it is a loop which waits for a response from the database. Say the caller of this subroutine wants to have a timeout condition attached to this request.

To me the obvious C-style solution here is to pass the timeout value to the procedure and have it check its elapsed time as part of the loop, then break if it takes too long with an exception or a return value stating that a timeout occurred.

My question is this: Is there a more elegant way to do this timeout checking in Ada, perhaps using this select/or system? Or is the C-style technique as elegant as it gets for this kind of problem?

Re: Timeouts in Ada

[Dmitry A. Kazakov]

On Thu, 17 Jul 2014 01:59:53 -0700 (PDT), NiGHTS wrote:

> On Thursday, July 17, 2014 3:42:21 AM UTC-4, Dmitry A. Kazakov wrote:
>> 
>> This is a timed entry call. The callee must be a task's or a protected
>> object's entry.
> 
> Are you suggesting that the select/or would not work inside the main
> procedure?

?

> Say I had a subroutine which submits a query to a database in a
> non-blocking way. Thus it is a loop which waits for a response from the
> database.

The example is quite unrealistic. If the DB client supported asynchronous
requests, then it would be very unlikely polling. Any reasonably designed
client would use some waitable OS object instead, i.e. waiting will be
non-busy.

> Say the caller of this subroutine wants to have a timeout
> condition attached to this request.

In the polling scenario, the polling loop must check for timeout being
expired.

For non-busy waiting, OS usually provides means to specify a timeout. E.g.
WaitForSingleObject under Windows.

> To me the obvious C-style solution here is to pass the timeout value to
> the procedure and have it check its elapsed time as part of the loop, then
> break if it takes too long with an exception or a return value stating
> that a timeout occurred.

This is how most non-Ada API do.

An Ada API would have a choice between dressing the call up as a plain
subroutine and thus passing the timeout as a parameter or else exposing the
task or protected object and thus allowing explicit timed entry calls on
the caller's side.

> My question is this: Is there a more elegant way to do this timeout
> checking in Ada, perhaps using this select/or system?

An elegant way is the latter, i.e. exposing an entry.

> Or is the C-style
> technique as elegant as it gets for this kind of problem?

This is inelegant but has certain advantages:

1. Protected objects and tasks in Ada do not really support OO and
programming by extension.

2. Usually when the timeout is expired you want some action of the callee's
side, e.g. changing the state of the I/O request on the server like
canceling the outstanding requests, performing a rollback etc.

A timed entry call offers only caller's side response. It is possible to
incorporate server's side actions with entry calls using the technique of
requeueing, as I described earlier, but it could make things a bit
overcomplicated.

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

Re: Timeouts in Ada

[J-P. Rosen]

Le 17/07/2014 10:40, NiGHTS a écrit :

> I was mainly confused by the fact that the delay command was placed
> inside the body of a fork in the path of logic, making it seem as
> though in order to satisfy the syntax it had to do things
> concurrently. ARM seems to imply that it expects a delay in the body
> (first command?) as a condition to determine which path to take. I'm
> still a little fuzzy on the mechanics but I'm sure this will clear up
> as I do some more reading on the C variant.
> 
Hmmm... The intent is clearer if you write it this way:

select
   <entry call>
   <other statements>
or delay 10.0;
   <other statements>
end select;

But be aware NOT to try to understand the rendezvous in terms of
mutexes, conditional variables, and the like; it is a much higher level
communication mechanism. It's really a client exchanging data
synchronously with a server.

To me, mutexes are to concurrency what gotos are to sequential
programming: a low level tool which is best hidden behind higher level
constructs.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Timeouts in Ada

[Adam Beneschan]

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!

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 12:12:13 PM UTC-4, Adam Beneschan wrote:
> 
> 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

Your answer was highly intuitive, so thank you for your careful explanation. 

So even if the entry call takes an hour, it will still wait the full hour until it completes before entering the "or delay" section? This is what I am understanding so far.

Also, can two entry calls be placed like this?

    select call_1(params)
        ...
    or call_2(params)
        ...
    or delay 10
        ...
    end select

If so, how would it know which finishes first without having them run concurrently? Don't see a point in having them run one after the other.

I have also seen the select used with an "else". What exactly is the difference between "or" and "else"? Is "else" used when a "delay" is not involved? Otherwise I don't see the point in the "else" path.

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 5:48:56 AM UTC-4, Dmitry A. Kazakov wrote:
> 
> The example is quite unrealistic. If the DB client supported asynchronous
> 
> requests, then it would be very unlikely polling. Any reasonably designed
> 
> client would use some waitable OS object instead, i.e. waiting will be
> 
> non-busy.
> 

I've dealt with many database libraries which provide both blocking and non-blocking queries. The logic behind this is that the blocking function is best used in a dedicated query thread whereas non-blocking is typically used in a single-threaded model where the main process checks up on the state of the query object while it takes care of other things, perhaps updating a progress bar or some other task.

I tend to prefer non-blocking processes like this so I can set my own blocking priority (for instance usleep(250000)). I feel its more portable and manageable to control the block myself. 

Thank you for your answers. They have been very insightful.

Re: Timeouts in Ada

[Simon Wright]

NiGHTS <nights@unku.us> writes:

> So even if the entry call takes an hour, it will still wait the full
> hour until it completes before entering the "or delay" section? This
> is what I am understanding so far.

After the entry call has been accepted, the timeout is cancelled; Adam's
pseudocode had Wait_For_Rendezvous_To_Complete at that point. It could
wait for days to complete (not that that's a good idea).

> Also, can two entry calls be placed like this?
>
>     select call_1(params)
>         ...
>     or call_2(params)
>         ...
>     or delay 10
>         ...
>     end select
>
> If so, how would it know which finishes first without having them run
> concurrently? Don't see a point in having them run one after the
> other.

Not allowed: ARM 9.7.2 [1].

> I have also seen the select used with an "else". What exactly is the
> difference between "or" and "else"? Is "else" used when a "delay" is
> not involved? Otherwise I don't see the point in the "else" path.

This is in ARM 9.7.3. If the entry_call_alternative (the part after the
select) can't be accepted immediately, the else part is executed.

[1] http://www.ada-auth.org/standards/12rm/html/RM-9-7-2.html

Re: Timeouts in Ada

[NiGHTS]

On Thursday, July 17, 2014 1:11:54 PM UTC-4, Simon Wright wrote:
> 
> > So even if the entry call takes an hour, it will still wait the full
> 
> > hour until it completes before entering the "or delay" section? This
> 
> > is what I am understanding so far.
> 
> 
> 
> After the entry call has been accepted, the timeout is cancelled; Adam's
> 
> pseudocode had Wait_For_Rendezvous_To_Complete at that point. It could
> 
> wait for days to complete (not that that's a good idea).
> 
> 
> 
> > Also, can two entry calls be placed like this?
> 
> >
> 
> >     select call_1(params)
> 
> >         ...
> 
> >     or call_2(params)
> 
> >         ...
> 
> >     or delay 10
> 
> >         ...
> 
> >     end select
> 
> >
> 
> > If so, how would it know which finishes first without having them run
> 
> > concurrently? Don't see a point in having them run one after the
> 
> > other.
> 
> 
> 
> Not allowed: ARM 9.7.2 [1].
> 
> 
> 
> > I have also seen the select used with an "else". What exactly is the
> 
> > difference between "or" and "else"? Is "else" used when a "delay" is
> 
> > not involved? Otherwise I don't see the point in the "else" path.
> 
> 
> 
> This is in ARM 9.7.3. If the entry_call_alternative (the part after the
> 
> select) can't be accepted immediately, the else part is executed.
> 
> 
> 
> [1] http://www.ada-auth.org/standards/12rm/html/RM-9-7-2.html

Again, your links were very helpful. It led me to the following discussion on this topic which I feel completely satisfies my curiosity on this subject.

http://archive.adaic.com/standards/83lrm/html/lrm-09-07.html

Thank you all for bearing with me and taking the time to help me with this.

Re: Timeouts in Ada

[Adam Beneschan]

On Thursday, July 17, 2014 9:46:04 AM UTC-7, NiGHTS wrote:

> Your answer was highly intuitive, so thank you for your careful explanation. 

Glad it helped. 
> 
> So even if the entry call takes an hour, it will still wait the full hour until it completes before entering the "or delay" section? This is what I am understanding so far.

If the entry is *selected* right away, but the rendezvous takes an hour (i.e. the body of the ACCEPT statement just sits there), then yes, the code will wait.  Normally, a rendezvous that could wait an hour shouldn't be written.  I think the idea is that rendezvous should be completed fairly quickly.

> Also, can two entry calls be placed like this? 
> 
>     select call_1(params)
>         ...
>     or call_2(params)
>         ...
>     or delay 10
>         ...
>     end select

No.  See my comments below.

> If so, how would it know which finishes first without having them run concurrently? Don't see a point in having them run one after the other.

If this statement *were* implemented, it would choose whichever entry call became *available* first.  Then when one of them, say call_2, became available, it would cancel all the other entry calls, wait for the call_2 rendezvous to complete, and execute the sequence of statements after the call_2.  In theory, this shouldn't need anything to "run concurrently".  The current task would go into a wait state, and the tasking implementation would have a list of entries the task was waiting for, and the implementation would wake it up as soon as one of those entries could be selected.

In practice, however, apparently it's too complicated to implement.  I don't know the details.  It may be that it's too hard to implement when combinations of features are used.  In any case, the language designers considered adding this ability (SELECT on multiple entries), but decided against it.

 
> I have also seen the select used with an "else". What exactly is the difference between "or" and "else"? Is "else" used when a "delay" is not involved? Otherwise I don't see the point in the "else" path.

ELSE is pretty much the same as OR DELAY 0.0;.  It selects the entry if it happens to be available right away (in which case it waits for the rendezvous to complete, then executes any other statements after the entry call).  Otherwise it gives up immediately and jumps right to the sequence of statements after the ELSE.  Note that, unlike OR, the first statement after ELSE is not special and can be any Ada statement.

                                  -- Adam

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 09:46 AM, NiGHTS wrote:
>
> Also, can two entry calls be placed like this?
>
>      select call_1(params)
>          ...
>      or call_2(params)
>          ...
>      or delay 10
>          ...
>      end select

No. However, one can write

select
    delay 10.0;
    ...
then abort
    select
       Call_2 (...);
       ...
    then abort
       Call_1 (...);
       ...
    end select;
end select;

It's possible, if you do this, that zero, one, or both entry calls may complete, 
and figuring out which "..." gets executed for the various cases is not easy.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 10:11 AM, Simon Wright wrote:
>
> After the entry call has been accepted, the timeout is cancelled; Adam's
> pseudocode had Wait_For_Rendezvous_To_Complete at that point. It could
> wait for days to complete (not that that's a good idea).

Unless it's requeued with abort; then the delay can still cancel the entry call.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 10:58 AM, NiGHTS wrote:
>
> Again, your links were very helpful. It led me to the following discussion on
> this topic which I feel completely satisfies my curiosity on this subject.
>
> http://archive.adaic.com/standards/83lrm/html/lrm-09-07.html

Unfortunately, no. Things are quite different between Ada 83 and Ada 95 (and 
later). This is much simpler in Ada 83 because all entry calls result in a 
rendezvous, and if accepted that rendezvous must complete. Ada 95 introduced 
protected objects with entries and requeue, and it became much more complex.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 11:12 AM, Adam Beneschan wrote:
>
> If the entry is *selected* right away, but the rendezvous takes an hour (i.e.
> the body of the ACCEPT statement just sits there), then yes, the code will
> wait.  Normally, a rendezvous that could wait an hour shouldn't be written.
> I think the idea is that rendezvous should be completed fairly quickly.

A long rendezvous seems perfectly acceptable to me in some cases. Consider an 
external action that may take a long time, several tasks that need to have this 
external action taken, and multiple such actions must occur sequentially. I 
would almost certainly implement this as a task entry, even though the task 
would be passive, since potentially blocking operations are prohibited in a 
protected operation.

Sandén's FMS problem has an example of this: there is a single device for 
transporting jobs between the storage bins and the work floor. Transporting a 
single job may take minutes. If multiple jobs all need transport, they must be 
transported sequentially, and the last one transported may have to wait many 
multiples of the time for a single transportation.

Personally, I think protected objects were a mistake. Formalizing the concept of 
a passive task would have been better than inventing a new concept, with a new 
reserved word, with unnecessary and impractical restrictions.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 12:38 AM, J-P. Rosen wrote:
>
> Not at all! In Ada, one task=one thread, there are no hidden threads.

Surely ATC involves a "hidden thread". After all,

select
    <trigger>
then abort
    <abortable part>
end select;

is shorthand for

declare
    task AP;

    task body AP is
    begin
       <abortable part>
    end AP;
begin
    <trigger>

    abort AP;
end;

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/16/2014 10:18 PM, NiGHTS wrote:
>
> 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.

You've had lots of good answers to this. I'm going to try to look at it a bit 
differently to see if that helps.

Ada's tasking features are high-level and biased towards safety. Things like 
mutexes are sort of like the machine code that Ada's tasking structures are 
implemented with, just as an if statement is implemented with conditional gotos. 
You shouldn't think in terms of conditional gotos, and you shouldn't think in 
terms of low-level concurrency primitives. In this case, your experience using 
low-level languages works against you.

Ada defines the effect of using its tasking features, not how that effect is 
obtained. You are asking about the latter. That is like asking how code is 
generated for an if statement. Unless you're a compiler writer, it's really not 
important, so long as you understand the effect of the if statement. And just as 
on this processor an if may be implemented using a BNE instruction, and on 
another with a JNZ, how Ada's tasking is implemented will vary based on the target.

Generally, between your code and the platform there will be an Ada run-time 
library (RTL). Your code will be translated into calls to the RTL.

If you're targeting bare metal, there will be nothing below the RTL. All tasking 
and scheduling will be done by the RTL.

If you're targeting an OS, generally the RTL will use OS services to implement 
tasking. Tasks will be mapped onto OS threads, delays onto timers, and so forth.

While an implementation might decide to create a thread or 2 as you suggest, 
it's unlikely. There's a task T that executes the select statement. Most likely 
T has the scheduler create a timer and queue the entry call, then blocks. 
Eventually something happens that causes the scheduler to make T runnable again, 
and some time after that the scheduler will run T again. Then T will look at the 
event that allowed it to run again and take one of the 2 branches based on that.

The important thing is that T waits for one of those 2 events (entry call going 
through or delay expiring) and then completes the corresponding branch of the 
select. How that is implemented is no more important than what machine code is 
generated for an if.

Finally, most of the answers talk about the delay being canceled when the entry 
call is accepted. Reality is more murky than that. The entry call can be 
accepted, then requeued "with abort", and the delay can still cancel the entry 
call, and the accept-requeue sequence can happen any number of times. Generally 
entry calls are "abort deferred", so if the call is accepted and is not 
currently requeued with abort, the call cannot be canceled. So a more complete 
answer may be, if the entry call has not been accepted, or has been accepted but 
is currently requeued with abort, then the time out will cancel the entry call. 
Otherwise the entry call will complete. I'm not clear about what happens if the 
entry call completes but the time out expires before it does, but I think in 
that case the select branch is completed and the or branch is ignored.

(Originally the semantics were defined in terms of the entry call being accepted 
because Ada 83 didn't have requeue. Ada 95 introduced requeue and things got murky.)

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[J-P. Rosen]

Le 17/07/2014 21:27, Jeffrey Carter a écrit :
> On 07/17/2014 12:38 AM, J-P. Rosen wrote:
>>
>> Not at all! In Ada, one task=one thread, there are no hidden threads.
> 
> Surely ATC involves a "hidden thread". After all,
> 
> select
>    <trigger>
> then abort
>    <abortable part>
> end select;
> 
> is shorthand for
> 
> declare
>    task AP;
> 
>    task body AP is
>    begin
>       <abortable part>
>    end AP;
> begin
>    <trigger>
> 
>    abort AP;
> end;
> 
Did you check this with an implementation? For one thing, Current_Task
must be the same in the abortable part and in the trigger...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Timeouts in Ada

[Adam Beneschan]

On Thursday, July 17, 2014 12:27:07 PM UTC-7, Jeffrey Carter wrote:
> On 07/17/2014 12:38 AM, J-P. Rosen wrote:
> 
> > Not at all! In Ada, one task=one thread, there are no hidden threads.
> 
> Surely ATC involves a "hidden thread". After all,
> 
> select
>     <trigger>
> then abort
>     <abortable part>
> end select;
> 
> is shorthand for
> 
> declare
>     task AP;
>  
>     task body AP is
>     begin
>        <abortable part>
>     end AP;
> begin
>     <trigger>
>     abort AP;
> end;

Not quite.  If the <trigger> is an entry call, and the entry can be selected immediately, the <abortable part> never starts (unless the entry is requeued-with-abort); your code would have the <abortable part> start, and then get aborted when the entry call is completed.  

If the trigger is an entry call and the entry is queued, *then* the abortable part is aborted when the entry call completes, not when it's selected.  

There are other cases where the language says the abortable part would never start, but in your code above, it's nondeterministic whether your abortable part would start or not.

Anyway, it's hard to say whether this involves a "hidden thread" or not.  J-P's statement makes no sense if we're talking about low-level or OS threads, since Ada says nothing about how tasks should be implemented, and it's possible to write a tasking implementation in which there is only one OS thread in which all tasks run, and there's nothing wrong with an implementation creating a new "hidden" OS thread that is unconnected to a task if necessary.  If we're talking about a conceptual kind of "thread", then we'd need a better definition of what we're talking about.  The RM uses the term "thread of control" but never really defines it, but RM 9(1) says "Each task represents a separate thread of control that proceeds independently and concurrently between the points where it interacts with other tasks."  In the context of the original question, I think that means that within a single task, there cannot be two sequences of statements that are executing at the same time, as the OP thought there were with the SELECT statement.  How this applies to ATC, I'm not sure.  But I think it's still true that you cannot have two statements in a single task executing at the same time, as long as you don't consider a DELAY to be "executing" while it's delaying, or an entry call to be "executing" when it's waiting for a rendezvous to complete.  

                               -- Adam

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 12:27 PM, Jeffrey Carter wrote:
>
> select
>     <trigger>
> then abort
>     <abortable part>
> end select;
>
> is shorthand for
>
> declare
>     task AP;
>
>     task body AP is
>     begin
>        <abortable part>
>     end AP;
> begin
>     <trigger>
>
>     abort AP;
> end;

Sorry, of course those aren't equivalent because I haven't included a mechanism 
to cancel the trigger when the abortable part completes. That's left as an 
exercise for the reader.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Dmitry A. Kazakov]

On Thu, 17 Jul 2014 10:10:10 -0700 (PDT), NiGHTS wrote:

> On Thursday, July 17, 2014 5:48:56 AM UTC-4, Dmitry A. Kazakov wrote:
>> 
>> The example is quite unrealistic. If the DB client supported asynchronous
>> requests, then it would be very unlikely polling. Any reasonably designed
>> client would use some waitable OS object instead, i.e. waiting will be
>> non-busy.
> 
> I've dealt with many database libraries which provide both blocking and
> non-blocking queries.

Non-blocking vs. blocking is not same as non-busy waiting vs. polling.
Usually if non-blocking I/O is supported then non-busy waiting is as well.
For example overlapped I/O provides many ways for non-busy waiting, an
event, GetOverlappedResult etc.

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

Re: Timeouts in Ada

[J-P. Rosen]

Le 17/07/2014 22:29, Adam Beneschan a écrit :
> J-P's statement makes no sense if we're talking about low-level or OS threads
I should have included my statement between <lawiers_hat_off> ...
</lawiers_hat_off>

In practice, and not to confuse the OP, tasks correspond to OS threads.
I meant that the language does not require creating separate threads
when not explicitely stated. Of course, a crazy implementation can do it
any way it pleases, provided it is equivalent to the model.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Timeouts in Ada

[Jeffrey Carter]

On 07/17/2014 12:51 PM, J-P. Rosen wrote:
>>
> Did you check this with an implementation? For one thing, Current_Task must
> be the same in the abortable part and in the trigger...

And Adam Beneschan wrote:

> Not quite.  If the <trigger> is an entry call, and the entry can be selected
> immediately, the <abortable part> never starts (unless the entry is
> requeued-with-abort); your code would have the <abortable part> start, and
> then get aborted when the entry call is completed.
>
> If the trigger is an entry call and the entry is queued, *then* the abortable
> part is aborted when the entry call completes, not when it's selected.
>
> There are other cases where the language says the abortable part would never
> start, but in your code above, it's nondeterministic whether your abortable
> part would start or not.

"Shorthand", of course, was shorthand for "roughly equivalent to", or maybe 
"intended to be better than ..., which is what people did in Ada 83".

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

Re: Timeouts in Ada

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyfvi0xy0w.fsf@pushface.org...
> NiGHTS <nights@unku.us> writes:
>
>> 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, there are probably only 2 threads here; the one running the code
> that executes the select, and the server task.

When ATC was designed for Ada 9x, we talked extensively about a 2 thread 
model as well as a 1 thread model. The rules are supposed to work for both. 
So the OP is correct, at least in the abstract.

The two thread model has problems with exception handling, and as such is 
guaranteed to be pretty expensive. The one thread model is thus used more, 
but it is guaranteed to have problems on systems like Windows that don't 
allow interrupting system calls.

Ergo, the best thing to do with ATC is to ignore that it exists.

                               Randy. 

Re: Timeouts in Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:lq7uhv$vao$1@dont-email.me...
> Le 17/07/2014 07:18, NiGHTS a écrit :
>> 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.
>>
> [Rest snipped, since based on wrong assertion]
>
> Not at all! In Ada, one task=one thread, there are no hidden threads.

Not true; ATC may need a hidden thread. But not here... (well, not unless 
the task supervisor itself uses a hidden thread, but that would probably 
exist during the life of the program).

> This kind of select is called a timed entry call.

Oops, you are right. For some reason, I thought this was an ATC. Ignore my 
previous response (unless you're thinking about ATC).

                              Randy.

Re: Timeouts in Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:lq9d2e$2on$1@dont-email.me...
> Le 17/07/2014 22:29, Adam Beneschan a écrit :
>> J-P's statement makes no sense if we're talking about low-level or OS 
>> threads
> I should have included my statement between <lawiers_hat_off> ...
> </lawiers_hat_off>
>
> In practice, and not to confuse the OP, tasks correspond to OS threads.
> I meant that the language does not require creating separate threads
> when not explicitely stated. Of course, a crazy implementation can do it
> any way it pleases, provided it is equivalent to the model.

Nothing crazy about it for implementing ATC. I remember talking about doing 
exactly that when Ada 9x was designed, and the rules were supposed to allow 
it. But it does require some hoops vis-a-vis exceptions, current task, etc.

ATC isn't useful on Windows unless one uses two threads, as most OS calls 
cannot be interrupted. The first example in the RM - 9.7.4(11) will never 
work on Windows unless a two thread model is used. We just discussed that in 
the ARG meeting -- in your office no less -- I'm surprised that you forgot 
about it.

Of course, we decided that it's not important that ATC is useful. (We added 
a disclaimer that cannot possibly be true of the first example.) Ergo, 
talking about ATC is a waste of time, no one should use it because you can't 
expect it to work (portably).

                                                 Randy.

Re: Timeouts in Ada

[Shark8]

On 21-Jul-14 17:34, Randy Brukardt wrote:
> Ergo, the best thing to do with ATC is to ignore that it exists.

When you have advice like that it kinda indicates a mistake.
Would you call ATC a mistake? (I've never used it, so I can't REALLY say 
-- though it seems that perhaps an entirely different structure [rather 
than overloading SELECT] may've helped.)

Re: Timeouts in Ada

[J-P. Rosen]

Le 22/07/2014 03:11, Shark8 a écrit :
> When you have advice like that it kinda indicates a mistake.
> Would you call ATC a mistake? (I've never used it, so I can't REALLY say
> -- though it seems that perhaps an entirely different structure [rather
> than overloading SELECT] may've helped.)

Randy said it was impossible to use /portably/. Although portability is
one of the primary goals of Ada, sometimes you have to sacrifice it for
some other goals - like having the job done, efficiency concerns, etc.

ATC is here because a number of guys from the real-time community called
for it. And it's certainly usable for bare-metal embedded targets. I
would say that if you are programming a bare-metal embedded target,
portability to Windows is not your first concern ;-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Timeouts in Ada

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> ATC is here because a number of guys from the real-time community
> called for it. And it's certainly usable for bare-metal embedded
> targets. I would say that if you are programming a bare-metal embedded
> target, portability to Windows is not your first concern ;-)

Our target was VxWorks, but we did a great deal of our testing on
Windows (on the host because of lack of target hardware, and on Windows
because of corporate/MoD insistence). We didn't use ATC for target code,
but we did use it on one or two occasions to ensure that a host test
couldn't hang indefinitely, but rather fail. As far as I remember we
tested that ATC would have the desired effect if triggered, but whether
it ever actually got triggered by some locked-up software-under-test I
can't say.

Re: Timeouts in Ada

[Randy Brukardt]

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:_Sizv.37414$ic5.15869@fx21.iad...
> On 21-Jul-14 17:34, Randy Brukardt wrote:
>> Ergo, the best thing to do with ATC is to ignore that it exists.
>
> When you have advice like that it kinda indicates a mistake.
> Would you call ATC a mistake? (I've never used it, so I can't REALLY 
> say -- though it seems that perhaps an entirely different structure 
> [rather than overloading SELECT] may've helped.)

It's hard to say. It might be useful in very limited circumstances. As 
Dmitry pointed out, the semantics of abort is so nasty that it is hard to do 
anything useful afterwards, unless what is aborted is carefully limited. 
(And the language gives no help in that.)

So, I'd suggest using it only if there is no other way (the same goes for 
abort proper, BTW), you are sure you know what you are doing, and the 
abortable part doesn't contain any I/O or other system calls [other than 
tasking], but it does contain lots of abort completion points. Then it can 
be used somewhat portably. Definitely stay miles away if any I/O is 
involved, or for that matter any writing of large global data structures.

                                    Randy.

Re: Timeouts in Ada

[Robert A Duff]

Sorry for answering rather late; I don't read this newsgroup very often.

NiGHTS <nights@unku.us> writes:

> Your answer was highly intuitive, so thank you for your careful explanation. 
>
> So even if the entry call takes an hour, it will still wait the full
> hour until it completes before entering the "or delay" section? This
> is what I am understanding so far.

No (see below).

> Also, can two entry calls be placed like this?
>
>     select call_1(params)
>         ...
>     or call_2(params)
>         ...
>     or delay 10
>         ...
>     end select

No, that's illegal.  But it makes good sense, and it was proposed as a
feature of Ada 9X, but rejected.

> If so, how would it know which finishes first without having them run
> concurrently?

It doesn't matter which finishes first.  What matters is which STARTS
first.  If the above were legal, it would mean "do whichever of the 3
alternatives is ready to go first".  Hence "or" in the syntax -- we
never execute more than one alternative.

If call_1 is selected before 10 seconds elapses, then the statements
after "delay 0.0;" are not executed.

In more mechanistic terms, you need to understand the concept of an
entry being "open", which is defined in the RM.  Basically, "open" means
the entry is ready to go.  And you can think of "delay 10.0" as an entry
call that will become open after 10 seconds of elapsed time, and has an
empty body.  So it goes roughly according to this pseudo code:

    Is call_1 open?
        If so, do the entry call, and do the following "...", and we're
        all done.
        
        If not, enqueue call_1, and ask is call_2 open?

            If so, CANCEL call_1, do the call_2 entry call, and the
            following "...", and we're done.

            If not, enqueue call2.  Is "delay 10.0" open (i.e. have 10
            seconds elapsed)?

                If so, cancel the two entry calls, and do the "..." after
                the delay, and we're done.

                If not, enqueue the delay (i.e. put it on some timer
                queue).  Now we've got 3 things enqueued.  This task now
                blocks (goes to sleep).  It will be awakened by one of
                those 3 things, whichever happens first.  Whichever
                happens first will cancel the other two.  If, for
                example, call_2 becomes open first, call_1 and the delay
                are canceled, then the body of call_2 is executed, and
                then the "..." after call_2.  If call_2 takes an hour to
                run, the delay alternative is still not executed; what
                matters is whether call_2 became open (i.e. ready to
                START) within 10 seconds.

>... Don't see a point in having them run one after the
> other.

They don't.  In all cases, only one of the 3 "..." above is executed.
And only one entry body (or accept) is executed.

> I have also seen the select used with an "else". What exactly is the
> difference between "or" and "else"? Is "else" used when a "delay" is
> not involved? Otherwise I don't see the point in the "else" path.

"else" means exactly the same thing as "or delay 0.0;".

So this:

    select
        Entry_1(...);
        ...
    else
        ...
    end select;

means:

    Is Entry_1 open?
        If so, execute it, and the following "...".
        If not, execute the "..." after "else".

In other words, it means "do Entry_1 if it is open RIGHT NOW".

- Bob

Re: Timeouts in Ada

[AdaMagica]

   select
     call_1(params)
   or
     call_2(params)
   or
     delay 10
   end select

The model in Ada is a set of counters (or cash points in a supermarket), an every day experience: You (as a person) can only queue before one of them. That's why it is not allowed in the syntax.

Re: Timeouts in Ada

[Robert A Duff]

AdaMagica <christ-usch.grein@t-online.de> writes:

>    select
>      call_1(params)
>    or
>      call_2(params)
>    or
>      delay 10
>    end select
>
> The model in Ada is a set of counters (or cash points in a
> supermarket), an every day experience: You (as a person) can only
> queue before one of them. That's why it is not allowed in the syntax.

It makes perfect sense to enqueue on multiple entries.
In fact, "select call_1 or delay..." enqueues twice (once on
the entry call, and once on the timer queue).

Regarding your analogy: There's a supermarket near me where they have
just one queue, and the person at the head of the queue takes the first
available cash point.  In a sense, they're enqueued on multiple cash
points.  ;-)  Like the multi-way call proposed (and rejected) for Ada 9X,
they only use one.

I think the reason multiple entries are not allowed is that during the
Ada 9X project, it was thought to be too hard to implement.
Or too hard to implement on existing implementations (which of course
had not been designed for that).

- Bob

Re: Timeouts in Ada

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccppgu9398.fsf@shell01.TheWorld.com...
...
> I think the reason multiple entries are not allowed is that during the
> Ada 9X project, it was thought to be too hard to implement.
> Or too hard to implement on existing implementations (which of course
> had not been designed for that).

It wasn't so much that it was too hard to implement, but that it was too 
hard to implement better than a programmer could write themselves. I recall 
something about essentially having to poll the entries. I don't know 
off-hand if there would have been some way to implement it sensibly if one 
was starting from scratch; I do remember that none of the 3 teams that 
analyzed the feature could come up with an efficient implementation. The 
real problem was that the people that were requesting the feature were 
hard-real time types that expect everything to happen immediately -- and 
that's not how this was going to work in practice.

We also analyzed ATC, which is equally expensive. But of course that did get 
in, because the expensive implementation is OK for the sorts of uses that it 
puts too.

It would be interesting to find those papers; I'm sure I still have them in 
a dusty box somewhere. (Our paper should also be on-line somewhere here, but 
it's not on my current computer, so finding it would be interesting.)

                             Randy.

Re: Timeouts in Ada

[AdaMagica]

On Thursday, July 24, 2014 5:37:39 PM UTC+2, Robert A Duff wrote:

> It makes perfect sense to enqueue on multiple entries.
> In fact, "select call_1 or delay..." enqueues twice (once on
> the entry call, and once on the timer queue).

That wasn't my point. I just indicated the model.

> Regarding your analogy: There's a supermarket near me where they have
> just one queue, and the person at the head of the queue takes the first
> available cash point.  In a sense, they're enqueued on multiple cash
> points.  ;-)  Like the multi-way call proposed (and rejected) for Ada 9X,
> they only use one.

That's a very sensible service - I often wish supermarkets here had this model. I find this only in airport counters.

But this is not the same as

>    select
>      call_1(params);
>    or
>      call_2(params);
>    or
>      delay 10;
>    end select;

In your supermarket, there is just one queue, and on the top, you are dispatched to a free cash point, and all of those do the same.

In that multiple select above, the different entries all would/could do different things. In your model: You queue before a gasoline station, a shoemaker, a hardware shop, an accomodation broker; you enter the first free of those.

Re: Timeouts in Ada

[Brad Moore]

On 2014-07-25 3:11 AM, AdaMagica wrote:
> On Thursday, July 24, 2014 5:37:39 PM UTC+2, Robert A Duff wrote:
>
>> It makes perfect sense to enqueue on multiple entries.
>> In fact, "select call_1 or delay..." enqueues twice (once on
>> the entry call, and once on the timer queue).
>
> That wasn't my point. I just indicated the model.
>
>> Regarding your analogy: There's a supermarket near me where they have
>> just one queue, and the person at the head of the queue takes the first
>> available cash point.  In a sense, they're enqueued on multiple cash
>> points.  ;-)  Like the multi-way call proposed (and rejected) for Ada 9X,
>> they only use one.
>
> That's a very sensible service - I often wish supermarkets here had this model. I find this only in airport counters.
>
> But this is not the same as
>
>>     select
>>       call_1(params);
>>     or
>>       call_2(params);
>>     or
>>       delay 10;
>>     end select;
>
> In your supermarket, there is just one queue, and on the top, you are dispatched to a free cash point, and all of those do the same.
>
> In that multiple select above, the different entries all would/could do different things. In your model: You queue before a gasoline station, a shoemaker, a hardware shop, an accomodation broker; you enter the first free of those.
>

I think Randy's point (or at least one of them) is that the programmer 
can already emulate this easily enough with existing Ada syntax (with a 
bit more effort admittedly) so on top of the other reasons for not 
implementing this, there is less motivation to introduce special syntax 
when the existing syntax already provides a way to achieve the same effect.

eg.

     - Declare two tasks, one whose body calls entry Call1 and the other 
whose body calls Call2.

     - Then instead of the select statement above, write:

    delay 10.0;
    abort T1;
    abort T2;

Brad

Re: Timeouts in Ada

[Dmitry A. Kazakov]

On Fri, 25 Jul 2014 02:11:29 -0700 (PDT), AdaMagica wrote:

> On Thursday, July 24, 2014 5:37:39 PM UTC+2, Robert A Duff wrote:
> 
> But this is not the same as
> 
>>    select
>>      call_1(params);
>>    or
>>      call_2(params);
>>    or
>>      delay 10;
>>    end select;

BTW, there could be any combination of counters:

   select
      call_1 (params);
   and
      call_2 (params);
   or
      delay 10;
   end select;

Calls or makes rendezvous with two entries indivisibly.

A use case is prevention of deadlocks with mutexes:

Task 1:

   select -- Acquire both or none
      Resource_1.Seize;
   and
      Resource_2.Seize;
   end select;

Task 2:

   select
      Resource_2.Seize;
   and
      Resource_1.Seize;
   end select;

is safe, while

Task 1:

    Resource_1.Seize;
    Resource_2.Seize;

Task 2:

   Resource_2.Seize;
   Resource_1.Seize;

is unsafe.

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