From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.13.221.19 with SMTP id g19mr13221909ywe.13.1464446322213;
        Sat, 28 May 2016 07:38:42 -0700 (PDT)
X-Received: by 10.157.56.116 with SMTP id r49mr279086otd.19.1464446322165;
 Sat, 28 May 2016 07:38:42 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!j92no122971qga.1!news-out.google.com!h125ni308ita.0!nntp.google.com!q6no2226890igz.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 28 May 2016 07:38:41 -0700 (PDT)
In-Reply-To: <niaaji$1nar$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=67.0.66.250;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 67.0.66.250
References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com>
 <ni68f8$1t85$1@gioia.aioe.org> <ni7iue$v9b$1@dont-email.me>
 <ni8u8j$1h74$1@gioia.aioe.org>
 <cf38020c-a34c-4c8d-b436-5e622100e58b@googlegroups.com>
 <niaaji$1nar$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8a5c6387-b476-4332-b0c9-611cbecd64b3@googlegroups.com>
Subject: Re: Advice, tasking and hardware
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Sat, 28 May 2016 14:38:42 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:30504
Date: 2016-05-28T07:38:41-07:00
List-Id: <comp.lang.ada>

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 );
>=20
> This is a very low-level and very fragile design. Consider ensuring that=
=20
> nothing comes between querying the length and the body that could change=
=20
> the string.

That's actually easy to do with Ada's tasking:
		select
		    accept Done do
			Finished:=3D True;
		    end Done;
		or
		    accept Get (Data : in String) do
			Internal_Data:=3D 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:=3D Internal_Data.Element'Length;
		    end Data;
		    accept Data (Item : out String) do
			Item:=3D Internal_Data.Element;
		    end Data;
		   =20
		end select;

> You start doing that with entry barriers risking running=20
> 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 th=
e private part and declare the public interface in the public portion as [i=
nline]subprograms which, in the body do the proper entry-calls.

package example is
  Function Get_String return String with Inline;
  -- ...
 =20
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=20
> get-length request dies prematurely, or that another task steals the=20
> 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 on=
e 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=
=20
> semaphore is more low-level than one based on monitor (the task serves=20
> 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 ob=
jects have their place, but they *AREN'T* capable of directly mapping to a =
protocol w/o forcing the manual creation of barriers.
=20
> P.S. The Ada-way of returning string is this:
>=20
>     entry Get_Text (Text : in out String; Last : out Integer);

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