multiple delay alternative

multiple delay alternative

[Mehdi Saada]

Hello !

In https://perso.telecom-paristech.fr/pautet/Ada95/chap28.htm, Ada tutorial's paragraph on the delayed rendezvous, it says the general form of this construct is:
select 
         delay <time>;
         <entry call>;
    or 
         delay <time>;
         <entry call>;
    or
         delay <time>;
         <entry call>;
    end select;

But in the RM timed entry calls are featured like this:
timed_entry_call ::= 
  select
   entry_call_alternative
  or
   delay_alternative
  end select;

What should I understand ?
I have trouble understanding the first construct, otherwise than "if nothing happens before n seconds, do that, AND THEN, if nothing happens before n2 seconds, do that, etc... as if
select
     delay 11.0;
     A;
or
     delay 12.0
     B;
end select;

is equivalent to
delay 10.0
select
     delay 1.0;
or
     delay 2.0;
end select;
But it's likely that I didn't guess right.

Re: multiple delay alternative

[Mehdi Saada]

Compilator confirmed only one delay allowed. I wonder what AdaTutor meant ? Is it an obsolete Ada 95 feature ? Strange !

Re: multiple delay alternative

[Bojan Bozovic]

On Sunday, March 4, 2018 at 7:22:58 PM UTC+1, Mehdi Saada wrote:
> Hello !
> 
> In https://perso.telecom-paristech.fr/pautet/Ada95/chap28.htm, Ada tutorial's paragraph on the delayed rendezvous, it says the general form of this construct is:
> select 
>          delay <time>;
>          <entry call>;
>     or 
>          delay <time>;
>          <entry call>;
>     or
>          delay <time>;
>          <entry call>;
>     end select;
> 
> But in the RM timed entry calls are featured like this:
> timed_entry_call ::= 
>   select
>    entry_call_alternative
>   or
>    delay_alternative
>   end select;
> 
> What should I understand ?
> I have trouble understanding the first construct, otherwise than "if nothing happens before n seconds, do that, AND THEN, if nothing happens before n2 seconds, do that, etc... as if
> select
>      delay 11.0;
>      A;
> or
>      delay 12.0
>      B;
> end select;
> 
> is equivalent to
> delay 10.0
> select
>      delay 1.0;
> or
>      delay 2.0;
> end select;
> But it's likely that I didn't guess right.

http://www.adaic.org/resources/add_content/docs/95style/html/sec_6/6-1-7.html

"The Ada language definition only guarantees that the delay time is a minimum. The meaning of a delay or delay until statement is that the task is not scheduled for execution before the interval has expired. In other words, a task becomes eligible to resume execution as soon as the amount of time has passed. However, there is no guarantee of when (or if) it is scheduled after that time because the required resources for that task might not be available at the expiration of the delay . "

Delay will simply stop execution (not schedule the task) for an amount of time until the condition needed is met, and then process the task entry. If you have both delayed and non-delayed entries for the same "accept" in "select" non-delayed will be executed (as far as I can tell).

I myself am willing to wait and see what the more experienced have to say on this matter, as AdaTutor by John J. Herro I'm using don't cover delayed task entries at all.

Re: multiple delay alternative

[Robert Eachus]

On Sunday, March 4, 2018 at 11:08:25 PM UTC-5, Bojan Bozovic wrote:

> Delay will simply stop execution (not schedule the task) for an amount of time until the condition needed is met, and then process the task entry.

This is one of those confusing statements of reality that looks like it says something special.  If the delay expires and all processors are running higher priority tasks, the delayed entry call continues to wait, but now for reasons of priority.

When trying to understand what is going on, you can normally divide the tasks in a program into those that make entry calls, and those that accept entry calls.  (Yes, task initialization may do the opposite to start up a set of worker tasks.)  Now:

> If you have both delayed and non-delayed entries for the same "accept" in "select" non-delayed will be executed (as far as I can tell)...

>   select 
>    entry_call_alternative 
>   or 
>    delay_alternative 
>   end select;

From the calling side, this is the only delay alternative.  It says to wait on the entry for N seconds, then give up if the entry is not available in that time.

Tasks that are waiting to be called can have multiple accept statements available--this is the selective accept.  Looks similar, but it is on the accepting side.  Notice that one of the most common uses of the selective accept is to have a terminate alternative.  This results in an orderly shutdown of all waiting tasks.  Yes, if you don't need orderly, or need an emergency shutdown you can use an abort statement.

The important thing to remember is that tasks come in these two flavors, callers and servers.  There is an important subset of server tasks which always runs (once created) in the calling task's thread of control.  These have mostly been replaced by protected objects.

Oh, and sometimes you have worker tasks, which call an entry to get a work unit, eat up a chunk of CPU time, call an entry to deliver results then go back to the original entry call.  There are several ways to shut these down, but I haven't found a (non-ugly) version that uses a terminate alternative. (Aborting the whole group of worker tasks when all the work is done is often the most practical.)

Re: multiple delay alternative

[Dmitry A. Kazakov]

On 04/03/2018 19:22, Mehdi Saada wrote:

> In https://perso.telecom-paristech.fr/pautet/Ada95/chap28.htm, Ada tutorial's paragraph on the delayed rendezvous, it says the general form of this construct is:
> select
>           delay <time>;
>           <entry call>;
>      or
>           delay <time>;
>           <entry call>;
>      or
>           delay <time>;
>           <entry call>;
>      end select;
> 
> But in the RM timed entry calls are featured like this:
> timed_entry_call ::=
>    select
>     entry_call_alternative
>    or
>     delay_alternative
>    end select;

I looks like a confusion between the selective accept (9.7.1) and the 
timed entry call (9.7.1). AFAIK the former can have multiple delay 
alternatives the latter naturally cannot.

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

Re: multiple delay alternative

[AdaMagica]

Am Sonntag, 4. März 2018 19:22:58 UTC+1 schrieb Mehdi Saada:
It's a selective accept 9.7.1.
RM (18)... the default queuing policy chooses arbitrarily among the
delay_alternatives whose expiration time has passed.

Re: multiple delay alternative

[Bojan Bozovic]

On Sunday, March 4, 2018 at 7:22:58 PM UTC+1, Mehdi Saada wrote:
> Hello !
> 
> In https://perso.telecom-paristech.fr/pautet/Ada95/chap28.htm, Ada tutorial's paragraph on the delayed rendezvous, it says the general form of this construct is:
> select 
>          delay <time>;
>          <entry call>;
>     or 
>          delay <time>;
>          <entry call>;
>     or
>          delay <time>;
>          <entry call>;
>     end select;
> 
> But in the RM timed entry calls are featured like this:
> timed_entry_call ::= 
>   select
>    entry_call_alternative
>   or
>    delay_alternative
>   end select;
> 
> What should I understand ?
> I have trouble understanding the first construct, otherwise than "if nothing happens before n seconds, do that, AND THEN, if nothing happens before n2 seconds, do that, etc... as if
> select
>      delay 11.0;
>      A;
> or
>      delay 12.0
>      B;
> end select;
> 
> is equivalent to
> delay 10.0
> select
>      delay 1.0;
> or
>      delay 2.0;
> end select;
> But it's likely that I didn't guess right.

Thank you Robert Eachus for this explanation, I have bookmarked this topic to use it for future reference. When I delve further into tasking, this will be of use to me, I hope.

Re: multiple delay alternative

[Mehdi Saada]

Ah, I see ! I definitely confused caller's and callee's side. In my defence, this is not obvious at all at first sight, either in the link I gave, or in the RM (it IS clear - well, probably ? - but you need to know what it is about more than I did, before reading/searching). Any way, BIG thanks.
It stands to reason that
select
>           delay <time>;
>           <entry call>;
>      or
>           delay <time>;
>           <entry call>;
>      or
>           delay <time>;
>           <entry call>;
>      end select;
is not allowed for the caller, or you could try and call on multiple entrees at the same time, and pick up on of them... meaningless.

Re: multiple delay alternative

[Dmitry A. Kazakov]

On 05/03/2018 14:50, Mehdi Saada wrote:
> or you could try and call on multiple entrees at the same time, and pick up on of them... meaningless.

Actually it is quite meaningful to call to multiple entries and/or 
engage in a "conference-rendezvous". But neither is directly supported.

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

Re: multiple delay alternative

[Mehdi Saada]

Do you know a language that support either of them, so that I can see better what you would like ?

Re: multiple delay alternative

[Dmitry A. Kazakov]

On 05/03/2018 16:09, Mehdi Saada wrote:
> Do you know a language that support either of them,

No

> so that I can see better what you would like ?

E.g. Waiting for a combination of events.

Presently it is implemented in Ada using requeue and entry families, 
which is a bit complicated.

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

Re: multiple delay alternative

[Jeffrey R. Carter]

On 03/05/2018 02:50 PM, Mehdi Saada wrote:
> It stands to reason that
> select
>>            delay <time>;
>>            <entry call>;
>>       or
>>            delay <time>;
>>            <entry call>;
>>       or
>>            delay <time>;
>>            <entry call>;
>>       end select;

This is confusing. Because it mentions entry calls, one might think it's a timed 
entry call, but that only allows a single delay alternative. And you don't 
usually have both a delay and an entry call in the same branch. A selective 
accept can have multiple delay alternatives, but has accept statements rather 
than entry calls. Again, you don't usually have a delay and an accept in the 
same branch.

> is not allowed for the caller, or you could try and call on multiple entrees at the same time, and pick up on of them... meaningless.

In Ada, you can do

select
    Entry_1;
then abort
    Entry_2;
end select;

Need more than 2? No problem; these can be nested

select
    Entry_1;
then abort
    select
       Entry_2;
    then abort
       Entry_3;
    end select;
end select;

The semantics of this seem somewhat confusing, though. While it's possible that 
only one of the entry calls will complete, it's also possible that any number of 
them will complete, including all of them.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: multiple delay alternative

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> In https://perso.telecom-paristech.fr/pautet/Ada95/chap28.htm, Ada
> tutorial's paragraph on the delayed rendezvous, it says the general
> form of this construct is:
> select 
>          delay <time>;
>          <entry call>;
>     or 
>          delay <time>;
>          <entry call>;
>     or
>          delay <time>;
>          <entry call>;
>     end select;
>
> But in the RM timed entry calls are featured like this:
> timed_entry_call ::= 
>   select
>    entry_call_alternative
>   or
>    delay_alternative
>   end select;
>
> What should I understand ?

The text in the tutorial is wrong, because the text immediately above it

    "Bill is not quite as hungry for his second meal so he is willing to
    wait for a short period at the restaurant, but if he is not served
    within one tenth of an hour, he will go to the Burger Boy for
    lunch. The single statement in lines 35 through 40 replaces the
    single statement in the previous program. In Ada terms, the task
    named Bills_Day will wait .1 hour for the Restaurant task to reach
    its entry point, after which it will call the entry point of
    Burger_Boy and wait no matter how long it takes to be served there."

shows that it's discussing entry *calls* and, as you note, there can
only be one delay alternative.

The sample code([1], from the "The Delayed Entrypoint" section, clearly
shows this.

[1] https://perso.telecom-paristech.fr/pautet/Ada95/e_c28_p3.ada

Re: multiple delay alternative

[Anh Vo]

On Monday, March 5, 2018 at 3:28:13 PM UTC-8, Simon Wright wrote:
> Mehdi Saada <00120260a@gmail.com> writes:
>  
> [1] https://perso.telecom-paristech.fr/pautet/Ada95/e_c28_p3.ada

My nick pick of this tutorial is on HOURS constant. It should have been defined as 

   HOURS : constant := 60.0 * 60.0;  --truly an hour

Then, it would take around an hour to run :-) 

Anh Vo

Re: multiple delay alternative

[Mehdi Saada]

So it really was confusing after all. It forced me to deep and read hours long everything about multitasking I could. Down to the intriquacies of "requeue", which is a really nice feature by the way. I can't say I didn't like it... many times I thought of things before actually reading them, and it's actually quite rewarding intellectually, when you can do that.
I've come with some questions and requests for confirmation as well, that I'll post tomorrow. Thanks for this point in particular. Was the guy who wrote this confused himself or what ? He hasn't been lacking in teaching skills at all so far.

Before that, one thing I can't get, even after asking other people:
for protected objects, in a protected procedure, when it's blocked, because a reading (protected function) or an entry is being served, are the calls to the procedure put on a queue as with entries ?
Someone said me the advantage of protected procedures was that you don't have to wait, but I read also they were exclusive with each others... damn.

Re: multiple delay alternative

[Robert Eachus]

On Monday, March 5, 2018 at 8:50:51 PM UTC-5, Mehdi Saada wrote:

> Before that, one thing I can't get, even after asking other people:
> for protected objects, in a protected procedure, when it's blocked, because a reading (protected function) or an entry is being served, are the calls to the procedure put on a queue as with entries ?
> Someone said me the advantage of protected procedures was that you don't have to wait, but I read also they were exclusive with each others... damn.

If a task calls an entry of a protected object, and has to wait, it waits, if you will, before the entry.  You can use select statements to wait, or even abandon the entry call immediately.  For subprograms of a protected object, the call is evaluated immediately, even if the protected object is busy.  Then procedure calls are executed sequentially.  After each protected action the entry queues are checked.  If a protected function call is active, all waiting function calls (again parameters evaluated immediately) are executed simultaneously before the entry queues are again checked.

Randy, is this right for the default rules?  I never bother because 9.5.1 (8..18) and the following notes mean I need to get the behavior right for well spaced calls, and the implementation will sort races however they fall out.  In other words, I can't really tell what order things happen in the case of truly simultaneous calls from different tasks--and CPU cores.  All I get is that the invariants and pre- and post- conditions hold.

The invariants are:

1) Only one entry or externally called procedure can be active at any point in time.
2) An entry or externally called procedure can call (internally) other procedures or functions without blocking.
3) If an externally called function is active, many other function calls can (in theory) be active, but no procedure or entry calls.
4) The state of the protected object (internal variables) cannot be changed by a function call.  However, local variables in the function can change, for example the index of a loop statement.

If you want to design complex protected objects, another important point/gotcha is that "potentially blocking" actions shouldn't occur within the protected body.  That effectively limits you to fairly standard synchronizing constructs.  The examples at the bottom of 9.4 are a good place to start.

Re: multiple delay alternative

[J-P. Rosen]

Le 06/03/2018 à 02:50, Mehdi Saada a écrit :
> Before that, one thing I can't get, even after asking other people: 
> for protected objects, in a protected procedure, when it's blocked,
> because a reading (protected function) or an entry is being served,
> are the calls to the procedure put on a queue as with entries ? 
> Someone said me the advantage of protected procedures was that you
> don't have to wait, but I read also they were exclusive with each
> others... damn.
This is kind of subtle.

From the formal (i.e. lawyer) POV:
Queues are not required by the language. On a multi-processor, one
processor could be actively looping on a lock until the lock is
released. OTOH, if you are using the Ceiling_Locking locking policy on a
mono-processor, the management of priorities is sufficient to guarantee
exclusive access without requiring queues.

The important point is that the time a task is blocked waiting on the
lock can be computed. Hence the ban on "potentially blocking operations"
in protected operations.

From the implementation POV:
Nothing prevents an implementation from using a conventional queue of
tasks waiting for the protection lock.

-- 
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: multiple delay alternative

[Jeffrey R. Carter]

On 03/06/2018 02:50 AM, Mehdi Saada wrote:
> 
> Before that, one thing I can't get, even after asking other people:
> for protected objects, in a protected procedure, when it's blocked, because a reading (protected function) or an entry is being served, are the calls to the procedure put on a queue as with entries ?
> Someone said me the advantage of protected procedures was that you don't have to wait, but I read also they were exclusive with each others... damn.

An entry call may block, because the barrier is False or the task is not 
executing an accept for it. A protected procedure call doesn't block, because it 
has no barrier, but it may have to wait to obtain exclusive access to the PO. 
Blocking and waiting are 2 different concepts.

If you have multiple calls to protected procedures of a PO at the same time, I 
don't see anything that prevents that being implemented with a queue of callers. 
The important thing is that the calls are mutually exclusive and higher priority 
callers have precedence over lower priority ones.

-- 
Jeff Carter
"He that hath no beard is less than a man."
Much Ado About Nothing
132

Re: multiple delay alternative

[Mehdi Saada]

> If a protected function call is active, all waiting function calls (again parameters evaluated immediately)
Ok, I got this. Simultaneous, but blocked by use of protected procedures and entries.
> For subprograms of a protected object, the call is evaluated immediately, even if the protected object is busy.  Then  procedure calls are executed sequentially
Still don't get it, sorry... What's the difference *as far as waiting to be served one after the other* ?
I know, there's no guard, and the only thing that matter is if a procedure or entry is active at the same time. Ok. Then what... the caller tasks are still waiting to execute the procedure, one after the other, and before they are blocked... Just like with an entry ?? You see where I'm stucked ? Other subtleties don't concern me for now. I must get the essential difference in behavior first.
Maybe a drawing or an actual example would do the trick ;-) Sorry, I feel like I'm not always that smart :-)

Re: multiple delay alternative

[Dmitry A. Kazakov]

On 06/03/2018 11:31, Mehdi Saada wrote:
>> If a protected function call is active, all waiting function calls (again parameters evaluated immediately)
> Ok, I got this. Simultaneous, but blocked by use of protected procedures and entries.
>> For subprograms of a protected object, the call is evaluated immediately, even if the protected object is busy.  Then  procedure calls are executed sequentially
> Still don't get it, sorry... What's the difference *as far as waiting to be served one after the other* ?
> I know, there's no guard, and the only thing that matter is if a procedure or entry is active at the same time. Ok. Then what... the caller tasks are still waiting to execute the procedure, one after the other, and before they are blocked... Just like with an entry ?? You see where I'm stucked ? Other subtleties don't concern me for now. I must get the essential difference in behavior first.

The difference is that execution of the body of a protected 
function/procedure/entry is logically instant. This why blocking 
operations are prohibited within. Therefore a protected function or 
procedure logically never waits = never blocked. An entry call can be 
blocked and logically not instant until gets executed. Functions are 
like procedures except that logically allowed to run parallel to each other.

What an implementation makes of all this is up to the vendor and machine 
architecture.

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

Re: multiple delay alternative

[Mehdi Saada]

> The difference is that execution of the body of a protected function/procedure/entry is logically instant. Therefore a protected function or
procedure logically never waits = never blocked.
> Functions are like procedures except that logically allowed to run parallel to each other. Ok, but aren't calls on protected procedures blocked when other tasks is executing them ?
And, hum, I don't understand of "logically" stuff, I would like to stick with practical cases for the moment...

Re: multiple delay alternative

[Dmitry A. Kazakov]

On 06/03/2018 14:43, Mehdi Saada wrote:
>> The difference is that execution of the body of a protected function/procedure/entry is logically instant. Therefore a protected function or
> procedure logically never waits = never blocked.
>> Functions are like procedures except that logically allowed to run parallel to each other. Ok, but aren't calls on protected procedures blocked when other tasks is executing them ?
> And, hum, I don't understand of "logically" stuff, I would like to stick with practical cases for the moment...

Logically = in the sense of program logic.

A practical case is when you looping in a protected body when other 
tasks try to insert or read something into/from a shared container 
object, totally unrelated to the said body.

If the implementation of exclusion is based on taking a process-wide 
spin lock, the body would block all container operations, while the 
program logic would view these container operations non-blocking.

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

Re: multiple delay alternative

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:212bf1a1-1bcc-4474-b1f6-b98c1461ff07@googlegroups.com...
>>> Functions are like procedures except that logically allowed to run 
>>> parallel to each other.

> Ok, but aren't calls on protected procedures blocked when other tasks is 
> executing them ?

Not necessarily. On a monoprocessor, you are right in that waiting is 
essentially the same as blocking (the current task has to be suspended so 
that the protected operation can run and complete).

But on a multiprocessor, this is different as the protected operation is 
actively running on a different thread. So the task that is waiting is doing 
literally that, waiting for the lock to change. This does not necessarily 
cause the task to be suspended, it's not an abort point, and so on. It's 
often just a loop:

      while not Protected.Lock loop
           null; -- Possibly waste some time here.
      end loop;

In a properly designed protected object, the time of operations will be 
short and this will not waste significant processing time. (And it doesn't 
happen that much in practice, tasks usually are doing other things than 
calling POs.) So just wasting time in this way is the often the most 
efficient thing to do, as blocking (which requires a full context switch) is 
rather expensive.

                                   Randy.