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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Advice, tasking and hardware Date: Sat, 28 May 2016 17:45:29 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <25c43463-47ca-4021-82ee-299e6a075faa@googlegroups.com> <8a5c6387-b476-4332-b0c9-611cbecd64b3@googlegroups.com> NNTP-Posting-Host: g5mwItfuOGVKEwkuGFLFAw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30505 Date: 2016-05-28T17:45:29+02:00 List-Id: 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