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!news1.google.com!proxad.net!newsfeed.stueberl.de!feed.news.tiscali.de!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Composing tasks and protected objects Date: Fri, 05 Aug 2005 20:09:24 +0200 Message-ID: <87oe8cz25n.fsf@mid.deneb.enyo.de> References: <87iryk1eic.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: albireo.enyo.de 1123265379 1880 212.9.189.177 (5 Aug 2005 18:09:39 GMT) X-Complaints-To: Cancel-Lock: sha1:RUDNUgkwZrEyP4T9tFAdPZZ5B6g= Xref: g2news1.google.com comp.lang.ada:3988 Date: 2005-08-05T20:09:24+02:00 List-Id: * Robert A. Duff: >> In short, I want to perform protected entry calls and selective accept >> in parallel. >> >> Is this possible at all, without writing lots of stupid wrappers? > > No. You cannot mix entry calls and accepts in the same select > statement. You can't mix entry calls with "terminate", either. Yes, of course the code does not compile. I thought that I might have missed something obvious and this syntax was left out on the grounds of orthogonality of language features or something like that. > The original Ada 9X design proposed to allow multiple entry calls in a > select, which would solve your main problem, which is waiting on > multiple events. Indeed. > Your two entries would then become entries of a protected object, > and the above select would call them. Whoever calls those two > entries would instead call protected procedures that trigger those > entries. Yes, this would solve the main multiplexing problem. > 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? > One workaround is to change the call to Get into an accept > -- i.e. make Get be an entry of this task, and arrange for it > to be called as appropriate. Yes, but this only half of the story. In order to decouple the sender from the receiver, I think I need some access-to-entry concept. I can only implement this using some wrapper. It seems that the synchronous interfaces of Ada 2005 would make this considerably easier. >>...If >> not, what was the justification for not integrating the two language >> features (protected objects/tasks) in this way? > > 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. > 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? 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.