Example question

Example question

[compguy45]

body Spreadsheet_Task is
    begin
        loop
            select
                accept Recalculate;
                Do_Recalculation;
            or
                accept Shutdown;
                exit;
            end select;
        end loop;
    end Spreadsheet_Task;

Tutorial says "If calls to both entries are already pending, one will be accepted non-deterministically." what does that mean? If calls are pending on bith entries it might happend that Shutdown is accepted and exits in which case thats not good solution at all

Re: Example question

[Martyn Pike]

On 26/10/2014 13:27, compguy45@gmail.com wrote:
> body Spreadsheet_Task is
>      begin
>          loop
>              select
>                  accept Recalculate;
>                  Do_Recalculation;
>              or
>                  accept Shutdown;
>                  exit;
>              end select;
>          end loop;
>      end Spreadsheet_Task;
>
> Tutorial says "If calls to both entries are already pending, one will be accepted non-deterministically." what does that mean? If calls are pending on bith entries it might happend that Shutdown is accepted and exits in which case thats not good solution at all
>
>

It basically means exactly what you said.  If calls are pending on both 
entries then it is not deterministic as to which one will be processed 
first.

If you want deterministic behaviour then in my opinion this is where 
protected objects should be used.  Particularly if you absolutely must 
check for the existence of a Shutdown event before checking for a 
Recalculate event.

Martyn

Re: Example question

[Shark8]

On 26-Oct-14 07:27, compguy45@gmail.com wrote:
> body Spreadsheet_Task is
>      begin
>          loop
>              select
>                  accept Recalculate;
>                  Do_Recalculation;
>              or
>                  accept Shutdown;
>                  exit;
>              end select;
>          end loop;
>      end Spreadsheet_Task;
>
> Tutorial says "If calls to both entries are already pending,
> one will be accepted non-deterministically." what does that
> mean? If calls are pending on bith entries it might happend
> that Shutdown is accepted and exits in which case thats not
> good solution at all
>

It means that if it enters the SELECT and there are already tasks 
waiting at the rendezvous for both entry-points then one will be chosen 
"at random". (Though I heard that some compilers /did/ have a 
deterministic behavior here.)

Perhaps you would need to add a guard to the Shutdown entry, something 
like the following: When Recalculate'Count = 0.
(I haven't really used tasking w/ guards, but I /think/ that'll work.)

Re: Example question

[Niklas Holsti]

On 14-10-26 15:27 , compguy45@gmail.com wrote:
> body Spreadsheet_Task is
>     begin
>         loop
>             select
>                 accept Recalculate;
>                 Do_Recalculation;
>             or
>                 accept Shutdown;
>                 exit;
>             end select;
>         end loop;
>     end Spreadsheet_Task;
> 
> Tutorial says "If calls to both entries are already pending, one
> will be accepted non-deterministically." what does that mean?

One of the two entry calls will be accepted, the corresponding accept
statement will be executed, and there is no telling which entry will be
accepted. It might be Recalculate, it might be Shutdown.

> If calls are pending on bith entries it might happend that
> Shutdown is accepted and exits

Yes.

> in which case thats not good solution at all

Solution to what? You have not told us what is the problem to be solved.

For some applications, it makes sense to continue "calculating" as long
as there are requests, and let the Shutdown be delayed. For other
applications, the opposite approach is desired, and Shutdown should take
precedence.

The accept statement is neutral and does not favour one of its
alternatives over the others. However, you can use guards on the accept
alternatives to enforce some ordering.

For example, if you want to be sure of accepting and executing a
Shutdown even if there are also pending Recalculate requests, you can
guard the Recalculate alternative with the Count attribute of the
Shutdown entry:

      loop
          select
              when Shutdown'Count = 0 =>
                 accept Recalculate;
                 Do_Recalculation;
          or
              accept Shutdown;
              exit;
          end select;
      end loop;

Then, if there is a Shutdown call waiting when the select is executed,
the Recalculate alternative is closed, and the Shutdown call is certain
to be accepted.

If there are no pending Shutdown calls when the select is executed, both
alternatives are open, and the first call is accepted. If calls to
Recalculate and Shutdown are made simultaneously, one of the calls is
accepted, but we cannot know which one will be accepted. However, if it
happens to be the Recalculate call, on the next iteration of the loop
Shutdown'Count will be positive, the Recalculate alternative will be
closed, and the Shutdown call will be accepted.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Example question

[Simon Wright]

Shark8 <OneWingedShark@gmail.com> writes:

> It means that if it enters the SELECT and there are already tasks
> waiting at the rendezvous for both entry-points then one will be
> chosen "at random". (Though I heard that some compilers /did/ have a
> deterministic behavior here.)

Very probably: but a different compiler may very well have a different
behaviour.

Re: Example question

[J-P. Rosen]

Le 26/10/2014 15:18, Martyn Pike a écrit :
>> Tutorial says "If calls to both entries are already pending, one will
>> be accepted non-deterministically." what does that mean? If calls are
>> pending on bith entries it might happend that Shutdown is accepted and
>> exits in which case thats not good solution at all
>>
>>
> 
> It basically means exactly what you said.  If calls are pending on both
> entries then it is not deterministic as to which one will be processed
> first. 
No. "one of them is selected according to the entry queuing policy in
effect" (9.7.1(16))

It was never non deterministic. Implementation defined in previous
versions of the language.

> If you want deterministic behaviour then in my opinion this is where
> protected objects should be used.  Particularly if you absolutely must
> check for the existence of a Shutdown event before checking for a
> Recalculate event.
If you tell what kind of deterministic behaviour you want, it is easy to
write the expected behaviour with rendezvous.

-- 
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: Example question

[Robert A Duff]

Shark8 <OneWingedShark@gmail.com> writes:

> It means that if it enters the SELECT and there are already tasks
> waiting at the rendezvous for both entry-points then one will be chosen
> "at random".

It is not required to be random, and it is unlikely that any Ada
implementation would make it random.  By default, which one is
chosen is arbitrary.  The implementation will likely do something
simple, like always choosing the first one.  It won't roll dice.  ;-)

If you specify the Priority_Queuing policy, then the highest priority
call is chosen.  If there are multiple calls at that priority, it
chooses the first one.  See D.4(14).

>...(Though I heard that some compilers /did/ have a
> deterministic behavior here.)

Yes.  All compilers, I'd guess.

- Bob

Re: Example question

[Martyn Pike]

On 26/10/2014 15:46, J-P. Rosen wrote:
> Le 26/10/2014 15:18, Martyn Pike a écrit :
>>> Tutorial says "If calls to both entries are already pending, one will
>>> be accepted non-deterministically." what does that mean? If calls are
>>> pending on bith entries it might happend that Shutdown is accepted and
>>> exits in which case thats not good solution at all
>>>
>>>
>>
>> It basically means exactly what you said.  If calls are pending on both
>> entries then it is not deterministic as to which one will be processed
>> first.
> No. "one of them is selected according to the entry queuing policy in
> effect" (9.7.1(16))
>
> It was never non deterministic. Implementation defined in previous
> versions of the language.
>

Ok - the order cannot be assumed or ascertained by the order of the 
select statements in the source code.  I think that's what the OP is 
questioning.

>> If you want deterministic behaviour then in my opinion this is where
>> protected objects should be used.  Particularly if you absolutely must
>> check for the existence of a Shutdown event before checking for a
>> Recalculate event.
> If you tell what kind of deterministic behaviour you want, it is easy to
> write the expected behaviour with rendezvous.
>

Agreed it may be easy but my personal preference is to use protected 
objects.