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.66.249.202 with SMTP id yw10mr971421pac.12.1421933562265; Thu, 22 Jan 2015 05:32:42 -0800 (PST) X-Received: by 10.140.87.118 with SMTP id q109mr19171qgd.11.1421933562218; Thu, 22 Jan 2015 05:32:42 -0800 (PST) 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!hl2no65918igb.0!news-out.google.com!l7ni0qai.0!nntp.google.com!bm13no2268643qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 Jan 2015 05:32:42 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=130.232.105.117; posting-account=xMk30AoAAACEWgBjdZfjW9cEqRCtnf-j NNTP-Posting-Host: 130.232.105.117 References: <32208488-3a04-4d2a-8c64-840502dcf96d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <537cf2a9-e18d-4efb-adb5-fa1914f48e3a@googlegroups.com> Subject: Re: How to: communication between multiple tasks using protected objects - with no polling? From: Esa Riihonen Injection-Date: Thu, 22 Jan 2015 13:32:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:24692 Date: 2015-01-22T05:32:42-08:00 List-Id: keskiviikko 21. tammikuuta 2015 20.39.07 UTC+2 Jeffrey Carter kirjoitti: > On 01/21/2015 10:16 AM, Esa Riihonen wrote: > > keskiviikko 21. tammikuuta 2015 2.47.29 UTC+2 Jeffrey Carter kirjoitti: > > > >> select > >> PO1.Get (...); > >> then abort > >> PO2.Get (...); > >> end select; > >> > >> This might, however, result in both entries being executed. > > > > If I understand correctly this will indeed work when selecting between two PO entries. And it wouldn't matter if both got executed (although I just now can't see how this could happen). > > Why both might be executed is kind of complicated. There was a thread on here > about this some time ago. Consider the Ada-83 timed entry call: > > select > T.E; > or > delay 1.0; > end select; > > Ada 83 did not have protected types/objects or requeue, so if T.E was accepted > before the delay expired, the delay could be cancelled. If the delay expired > before the entry call was accepted then the entry call was aborted. > > Ada 95 introduced protected types/objects and requeue. This changed the > semantics somewhat. Since the entry call (which can now be to a task or PO > entry) can be requeued "with abort", the delay can't be canceled when the entry > call is accepted, since a requeued with abort call can be aborted when the delay > expires. Instead, we have to wait until the entry call completes before we can > cancel the delay. If the delay expires while the entry call is being executed, > that's OK because the execution of an entry call is abort deferred. > > Similar considerations apply to the ATC with both branches being entry calls and > result in the possibility of both calls being executed. > OK, I think I understand it now. It seems that even Ada is not totally free of its intricasies that can provide some surprises for an uninitiated ;) > > However, there seems not to be a natural way to expand this for more than > > those two. This seems to be syntactically correct (compiles): > > > > select > > PO1.Get (...); > > then abort > > select > > PO2.Get (...); > > then abort > > PO3.Get (...); > > end select > > end select; > > Yes, these can be nested as far as desired. > > > But I'm not sure whether it would actually do what I want it to do. That is: suspend there until any of the entry barriers becomes true and then exit the whole outermost select statement? > > Yes, but it might execute any number of the entry calls. > > > Even if it works I have a (minor) concern that it is not 'pretty' as it doesn't reflect the mutual equality of the entries - and thus has a feel of 'hack' there ;) > > It's not pretty and it's not a good idea. ATC is said to be a very complex and > heavyweight construct. I would only use it as a last resort. > > >> type Q_ID is (Q1, Q2, ...); > >> > >> type Q_Item (Q : Q_ID := Q_ID'First) is record > >> case Q is > >> when Q1 => > >> Item_1 : Q1_Item; > >> when Q2 => > >> Item_2 : Q2:Item; > >> ... > >> end case; > >> end record; > >> > >> protected Qs is > >> entry Get (Item : out Q_Item); > >> private -- Qs > >> Q_1 : Q1_Q; > >> Q_2 : Q2_Q; > >> ... > >> end Qs; > >> > >> protected body Qs is > >> entry Get (Item : out Q_Item) when > >> not Q_1.Is_Empty or not Q_2.Is_Empty or ... > >> is > >> -- Empty declarative part > >> begin -- Get > >> if not Q_1.Is_Empty then > >> Item := (Q => Q1, Item_1 => Q_1.Get); > >> elsif not Q_2.Is_Empty then > >> item := (Q => Q2, Item_2 => Q_2.Get; > >> ... > >> end if; > >> end Get; > >> end Qs; > > I guess I was asleep when I wrote that. For one thing I left out a way to get > things on the Qs. A better approach would be > > protected Queue is > procedure Put (Item : in Q_Item); > entry Get (Item : out Q_Item); > private -- Queue > Q : Q_Item_Q; > end Queue; > > protected body Queue is > procedure Put (Item : in Q_Item) is > -- Empty declarative part > begin -- Put > Q.Put (Item => Item); > end Put; > > entry Get (Item : out Q_Item) when not Q.Is_Empty is > -- Empty declarative part > begin -- Get > Q.Get (Item => Item); > end Get; > end Queue; At least that is more on my level of understanding - thanks. > If you're willing to restrict yourself to a single compiler vendor, Ada 12 has > synchronized queues as part of the standard library, and you could use one of > those instead of writing your own. For earlier versions of Ada, which are > supported by multiple compiler vendors, you could use PragmARC.Queue_Unbounded > (or Queue_Bounded) from the PragmAda Reusable Components rather than writing > your own. I guess it depends on whether writing your own PO is important for > your learning experience. Actually I think I at least would have to consider the synch queues in another part of my rehearsal program. Many thanks for all the help provided. > -- > Jeff Carter > "Run away! Run away!" > Monty Python and the Holy Grail > 58