some remarks and requests for confirmation on tasks and protected objects

some remarks and requests for confirmation on tasks and protected objects

[Mehdi Saada]

The same tutorial says, different names for the same overloaded entry, with different profils are seen as distinct entries… What does that mean exactly ? They still have the same queue/list of tasks waiting at the gate, right ? Seems logical, but I ask for confirmation.

> loop
>	select
>		when CONDITION1
>			accept	SERVICE₁ (…) do
>			end service₁ ;
>	or
>		when condition₂	
>			accept service2 (…) do
>			end Service2 ;
>	or
>		delay Période ;
>	end select ;
> end loop ;
It is then impossible to make the server terminate other than through an external termination.
Is it still the case in Ada2012 ? Even I can tell you could well want a task to took for termination (see that all other tasks of the same master are terminated are aborted, and that the master has run out of statements to execute) at each iteration, during 2 seconds, and if things are still running, iterate again. Delay alternative and terminate alternative still exclude each other… Is there another way to do the same ?

> if a server task is aborted, all calling tasks being served  « tasking error ».
=> Wouldn’t it have been possible to have more… specific exceptions when it comes to tasking ? Like « CALL_ON_ABORTED_OR_TERMINATED_TASK_ERROR ».

=> for protected objects, what does the compiler knows what is « input/ouput », to forbid them in entries/protected subprograms ? How does it differenciate such instructions (potentially blocking) from other, since they are implemented through predefined libraries ?

=> About requeue : wouldn’t that be useful to be able to ditch at least in mode parameters ?

About the syntax for entry family index : 
> entry_index_specification ::= for defining_identifier in discrete_subtype_definition
or : entry REQUEST (for P in PRIORITY) (formal_parameters) when Condition(P) is
Hum… what’s that ? Why not using normal subprogram parameters syntax, instead of something that looks like loop index specification, since something like that

procedure MAIN is

   type SPEED is (FAST, MEDIUM, SLOW, SNAIL);

   protected Selector is
      entry Answer_Query(SPEED)(Counter : INTEGER);
   end Selector;

   protected body selector is
      entry Answer_Query(for F in FAST..MEDIUM)(Counter : INTEGER) when TRUE is
      begin
         Put("FAST Query made"); Put(Counter, 3);
      end;
      entry Answer_Query(for F in SLOW..SNAIL)(Counter : INTEGER) when TRUE is
      begin
         Put("MEDIUM Query made"); Put(Counter, 3);
      end;
   end Selector;

is not allowed anyway ? It could, if those intervals war made to be static, or if the end of the end of the first and first of second interval, coincide.

About impossibility to give different discriminants to tasks or protected type objects :
I thought about that before… The problem is, discriminants can be given for limited records at initialization, which LOOKS like an affectation, from the syntactic POV at least. But tasks are even more limited than that, you can’t «:= » them at all.
What about using the same syntax as with entry index specification :
task type Selector is
   entry Answer_Query(SPEED)(Counter : INTEGER);
end Selector;
TASK_ARRAY: array (1..8) of SELECTOR(for P in 1..8, ANY_FUNCTION(P)) ;
(I saw there are existing solutions, proposed by Barnes, but not as clean as that.

Re: some remarks and requests for confirmation on tasks and protected objects

[Dmitry A. Kazakov]

On 06/03/2018 12:43, Mehdi Saada wrote:
> The same tutorial says, different names for the same overloaded entry, with different profils are seen as distinct entries… What does that mean exactly ? They still have the same queue/list of tasks waiting at the gate, right 

It is up to the implementation. I can imagine one with only one queue 
for all entries indexed by topics appearing in the guard expressions.

? Seems logical, but I ask for confirmation.
> 
>> loop
>> 	select
>> 		when CONDITION1
>> 			accept	SERVICE₁ (…) do
>> 			end service₁ ;
>> 	or
>> 		when condition₂	
>> 			accept service2 (…) do
>> 			end Service2 ;
>> 	or
>> 		delay Période ;
>> 	end select ;
>> end loop ;
> It is then impossible to make the server terminate other than through an external termination.

That's right, it is a language bug. However the terminate alternative is 
useless anyway because of another bug. Tasks practically cannot be 
components and Unchecked_Deallocation of a task is broken. So the 
pattern *always* is:

    loop
       select
       ...
       or accept Quit;
          exit;
       ...
       end select;
    end loop;

In the Finalize:

    procedure Finalize (X : Enclosing_Object) is
    begin
       ...
       if X.Worker /= null then
          X.Worker.Quit; -- Ask to terminate
          while not X.Worker'Terminated loop -- Wait it to terminate
             delay 0.01;
          end loop;
          Free (X.Worker); -- Now we can free it
       end if;
       ...
    end Finalize;

>> if a server task is aborted, all calling tasks being served  « tasking error ».
> => Wouldn’t it have been possible to have more… specific exceptions when it comes to tasking ? Like « CALL_ON_ABORTED_OR_TERMINATED_TASK_ERROR ».

You don't have a context for that. A natural solution is a rendezvous 
with the master when a child task crashes. Then on its behalf a 
rendezvous is engaged and the master can accept it:

    select
       accept T'Child_Fault
              (  Error : Exception_Occurrence;
                 Child : Task_ID
              )  do
          Put_Line ("My child failed me: " &
                 Exception_Information (Error));
       end T'Child_Fault;

The rendezvous follows the "chain of command" up to the environment task.

> => for protected objects, what does the compiler knows what is « input/ouput », to forbid them in entries/protected subprograms ? How does it differenciate such instructions (potentially blocking) from other, since they are implemented through predefined libraries ?

It is the programmer's responsibility. There are other things which are 
legal but should not be done there ether, e.g. loops, heap allocation etc.

> => About requeue : wouldn’t that be useful to be able to ditch at least in mode parameters ?

It certainly would, but it would require special rules of parameter 
matching.

> About the syntax for entry family index :
>> entry_index_specification ::= for defining_identifier in discrete_subtype_definition
> or : entry REQUEST (for P in PRIORITY) (formal_parameters) when Condition(P) is
> Hum… what’s that ?

[...]

> is not allowed anyway ? It could, if those intervals war made to be static, or if the end of the end of the first and first of second interval, coincide.

I think this is related to inability to change entry call parameters. 
That is the only practical use case for families. It would be actually 
enough to allow "hidden" entry parameters invisible and defaulted to the 
caller but visible to the protected object or task who can modify them 
before re-queuing.

> About impossibility to give different discriminants to tasks or protected type objects :
> I thought about that before… The problem is, discriminants can be given for limited records at initialization, which LOOKS like an affectation, from the syntactic POV at least. But tasks are even more limited than that, you can’t «:= » them at all.
> What about using the same syntax as with entry index specification :
> task type Selector is
>     entry Answer_Query(SPEED)(Counter : INTEGER);
> end Selector;
> TASK_ARRAY: array (1..8) of SELECTOR(for P in 1..8, ANY_FUNCTION(P)) ;
> (I saw there are existing solutions, proposed by Barnes, but not as clean as that.

There should be constructors, that solves this and many other issues. 
Limited returns and aggregates must be removed from the language. Yes, 
all existing code that uses them must be rewritten.

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

Re: some remarks and requests for confirmation on tasks and protected objects

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p7m5n3$fp6$1@gioia.aioe.org...
...
> I think this is related to inability to change entry call parameters. That 
> is the only practical use case for families.

Not sure fo the context here, but IMHO the only practical use case for a PO 
families is when you need to refer to a parameter in a barrier. (Unlike a 
task, there is only one body for the entire family, so the family index 
works like a parameter that can be used in a barrier.)

I'm not sure there is any real use case for a task family. The need to write 
separate accepts for each value makes it impractical to have more than a 
handful.

Moral: the only commonality between task and PO families is the way that 
they're called. The underlying implementation (both in Ada source and in the 
compiled program) is completely different, and thus so are the use cases.

                                      Randy.

Re: some remarks and requests for confirmation on tasks and protected objects

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Unchecked_Deallocation of a task is broken

It used to be that if you aborted an allocated task and then deallocated
it without waiting for 'Terminated the TCB (or something related, I
forget) would be left as garbage.

I believe this has been fixed for some time.

Re: some remarks and requests for confirmation on tasks and protected objects

[Dmitry A. Kazakov]

On 2018-03-06 21:25, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p7m5n3$fp6$1@gioia.aioe.org...
> ...
>> I think this is related to inability to change entry call parameters. That
>> is the only practical use case for families.
> 
> Not sure fo the context here, but IMHO the only practical use case for a PO
> families is when you need to refer to a parameter in a barrier. (Unlike a
> task, there is only one body for the entire family, so the family index
> works like a parameter that can be used in a barrier.)

Right, I am using it for waiting for a condition which cannot be used in 
a barrier. There is a family indexed by Boolean guarded by the expression

    Index = Toggle

When the awaited condition is not satisfied the call is requeued to the 
complementary entry (not Index).

When the condition is about to change Toggle is toggled and the 
complementary entry gets open.

> I'm not sure there is any real use case for a task family.

I never used that, maybe something like above.

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