Re: Advice, tasking and hardware

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

On 2016-05-28 16:38, Shark8 wrote:
> On Friday, May 27, 2016 at 2:27:37 PM UTC-6, Dmitry A. Kazakov wrote:
>> On 2016-05-27 21:13, Shark8 wrote:
>>> On Friday, May 27, 2016 at 1:50:50 AM UTC-6, Dmitry A. Kazakov wrote:
>>>> 6. Task entries cannot return unconstrained objects.
>>>
>>> This can be worked around:
>>>    We can add to the previous task the following:
>>> 	    Entry Data( Item : out Natural );
>>> 	    Entry Data( Item : out String );
>>
>> This is a very low-level and very fragile design. Consider ensuring that
>> nothing comes between querying the length and the body that could change
>> the string.
>
> That's actually easy to do with Ada's tasking:
> 		select
> 		    accept Done do
> 			Finished:= True;
> 		    end Done;
> 		or
> 		    accept Get (Data : in String) do
> 			Internal_Data:= String_Holder.To_Holder( Data );
> 		    end Get;
> 		or
> 		    accept Put do
> 			Ada.Text_IO.Put_Line( "DATA: "& Internal_Data.Element );
> 		    end Put;
> 		or
> 		    accept Data (Item : out Natural) do
> 			Item:= Internal_Data.Element'Length;
> 		    end Data;
> 		    accept Data (Item : out String) do
> 			Item:= Internal_Data.Element;
> 		    end Data;

You have a deadlock here when the order of calls is violated, e.g. when 
the caller does not call second Data entry.

>> Then consider a possibility that the caller of a
>> get-length request dies prematurely, or that another task steals the
>> string body and so on.
 >
> Again, precluded by the construction of the select statement shown above.

How do you preclude the caller from not calling the second Data entry?

> Once the task accepts a get-length it *MUST* next accept a get-data,
> so if multiple threads call the get-data then only one gets processed
> and that one is the only one that can then be accepted for a get-data
> because all the rest are waiting on get-length to be serviced.

That happen only if other tasks call Data entries in the exact same 
order. Which is why this is fragile.

The proper design of an Ada task is that *all* declared entries were 
callable in any task state. So if a certain order need to be enforced it 
is better done with barriers than with replicating accept statements and 
nesting selects.

> And tasking shows itself to be a higher-level construct; sure,

Not really. First of all, are you talking about the level of a language 
construct or about the level of a concurrent programming pattern? That is:

1. task type vs protected object type
2. semaphore vs monitor

It is frequently said that Ada concurrent programming primitives are 
higher level. The meaning of this is that they allow implementation of 
other primitives (event, mutex etc) and are integrated into the language 
control flow and type system.

Claiming that tasks are higher level than protected objects or reverse 
is meaningless.

> protected objects have their place, but they *AREN'T* capable of
> directly mapping to a protocol w/o forcing the manual creation of barriers.

As you see it is a quite bad idea to map protocol this way. When dealing 
with protocols, error handing is more important than protocol 
implementation itself. The latter is pretty much trivial. The former is 
what makes software reliable or not.

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