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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,97f543c7a63b8839 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Composing tasks and protected objects Date: 05 Aug 2005 14:26:07 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <87iryk1eic.fsf@mid.deneb.enyo.de> <87oe8cz25n.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1123266367 11194 192.74.137.71 (5 Aug 2005 18:26:07 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 5 Aug 2005 18:26:07 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3989 Date: 2005-08-05T14:26:07-04:00 List-Id: Florian Weimer writes: > * Robert A. Duff: > > The multi-way call feature was rejected primarily due to perceived > > difficulty of implementation, or perceived difficulty of *efficient* > > implementation. I did not agree with that argument. > > I could understand that argument if this language feature caused > uniform overhead on all protected operations, even if it isn't used > anywhere in the program. Is this really the case? I think I could implement multi-ways calls in such a way that there is zero or near-zero overhead for the currently-allowed features (plain calls, timed/conditional calls). But I have not proven that by doing so! Inefficiency is never a good reason to leave a feature out of a language. What matters is distributed overhead (i.e. when a feature causes inefficiency when you *don't* use it). There's also the issue that the implementation experiments done during the Ada 9X process were done on *existing* implementations, which were designed with the requirements of Ada 83 in mind. Adding a feature to an existing implementation is sometimes a lot harder than implementing it in a from-scratch design where the designer knows the requirements. > > As far as I know, mixing calls and accepts was not considered, > > perhaps because protected objects were intended to be a very lightweight > > mechanism (compared to task entries and accept statements). > > Hmm. It's still a bit strange that these language concepts are so far > away from each other. Well, if I were designing a language from scratch, I would have something like protected object entries. I would eliminate task entries entirely, and beef up PO entries so that can do all the useful things that task entries can do (such as waiting on multiple events). Task entries cause an enormous amount of unnecessary complexity in the language. Task types and task bodies could be completely eliminated, for example. As I said, I'm not sure what to do about terminate alternatives. > > I don't think terminates mixed with calls was considered, either. It's > > not clear what it should mean. Normally, "terminate" means the task > > terminates when there is no possibility that anybody might want to call > > the entries the task is waiting on. > > I think the alternative is also chosen if the master completes. > Wouldn't this lead to useful semantics in this case as well? A terminate alt is chosen if the master is complete, and all tasks dependent upon that master (directly or indirectly) are terminated, or are waiting at select-with-terminate statements. Given these conditions (and ignoring interrupts), the task's entries could never be called. But the same conditions in the entry call case do not imply that the called entry will never be triggered, because the called entry can be essentially anywhere, without regard to scopes and whatnot. > In the queue example, you'd give up your subscription to that queue, > but this would be handled by a controlled object declared in the task, > I think. I don't understand what you mean here. - Bob