Re: Advice, tasking and hardware

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

On 26/05/2016 21:35, Jeffrey R. Carter wrote:
> On 05/26/2016 12:26 AM, Dmitry A. Kazakov wrote:
>>
>> If you want interlocking for doing blocking calls use a mutex etc. A mutex
>> implementation based on protected objects is two actions: Seize and Release.
>
> To the OP: This is terrible advice. One should only use a low-level mechanism
> such as a semaphore when one can't achieve what one needs with the high-level
> mechanisms provided by the language: tasks and protected objects.

In practice it is not just a semaphore. The implementation protected 
object frequently carries higher level functions, e.g. protecting a 
queue of requests.

BTW an explicit queue is used only in the case of asynchronous 
processing of requests.

The rule of thumb is that if all requests are done synchronously to the 
caller, no task is used, only a protected interlocking object is. The 
entry of the protected object serves as a queue. If some requests are 
asynchronous, a task and a protected object are necessary.

A task alone is a rare case.

> Since there's
> no way for the compiler to know that the subprogram is potentially blocking,
> there's no reason not to put the call in a PO and make use of the high-level
> mutual exclusion it provides. Even if the system has problems with the call
> being in a protected operation, it's better to put a request for the call on a
> protected queue and have a task that gets the requests from the queue and makes
> the calls than to use a semaphore.

Tasks and protected objects have advantages and disadvantages. Regarding 
tasks the disadvantages are:

1. You need a task.

2. Ada tasks are difficult to compose, especially to have encapsulated 
tasks. Task components do not work in practical cases, so a pointer to 
the task will be required.

3. Ada tasks have problems with termination. The termination alternative 
design makes is unusable in most cases. There must be Shut_Down entry 
instead and a caller of it as well.

4. Task objects are tricky to deallocate. You must wait for task 
termination before calling Unchecked_Deallocation on it. Waiting within 
a Finalize is no fun.

5. Tasks entries have parameter passing problems. If you don't handle 
everything in the rendezvous in order to release the caller as soon as 
possible, you need to copy parameters and store them locally. The design 
of the select statement prevents doing this in a structured way. E.g.

    select
       accept String_Call (Text : String) do
          Local_Text := Text; -- Accept scope
       end;
       declare -- Handler's scope
          Local_Text : String -- This does not work!
       begin
          -- Process Local_Text
       end;
    or accept ...

6. Task entries cannot return unconstrained objects.

7 + 5-6. Task design requires sometimes a very complex state machine 
implementation to remember the order of accepted entries. It cannot be 
decomposed in a structured way because tasks are not composable. 
Protected objects have this too but they are somewhat simpler because 
some handling of the states could be done at the caller's side.

So in the end there could be a lot more low-level stuff regarding task 
maintenance, result passing, elaboration and finalization.

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