Re: Advice, tasking and hardware

[Shark8 <onewingedshark@gmail.com>]

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;
		    
		end select;

> You start doing that with entry barriers risking running 
> into a deadlock.

As you can see, no barrier needed.
This is one of the nice things about Ada's tasking: you can directly encode a protocol. -- And with package specifications, you can put the task in the private part and declare the public interface in the public portion as [inline]subprograms which, in the body do the proper entry-calls.

package example is
  Function Get_String return String with Inline;
  -- ...
  
private
  Task Text_IO is
  --...
end example;

package body example is
  Function Get_String return String is
    Length : Natural;
  begin
    Text_IO.Data( Length );
    Return Result : String(1..Length) do
      Text_IO.Data( Result );
    End Return;
  end Get_String;
  --...
end example;

> 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.
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.

> Note that the "discussion" started around the claim that design based on 
> semaphore is more low-level than one based on monitor (the task serves 
> as a monitor).
> (There was a reason why protected objects were introduced in Ada 95)

And tasking shows itself to be a higher-level construct; sure, protected objects have their place, but they *AREN'T* capable of directly mapping to a protocol w/o forcing the manual creation of barriers.
 
> P.S. The Ada-way of returning string is this:
> 
>     entry Get_Text (Text : in out String; Last : out Integer);

I would argue that the Ada way would be creating a function that returns the string of the proper length in the public part of the spec and keeping the implementation hidden in the body.