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.107.3.84 with SMTP id 81mr10754370iod.103.1520245076454; Mon, 05 Mar 2018 02:17:56 -0800 (PST) X-Received: by 10.157.41.184 with SMTP id n53mr752383otb.11.1520245076337; Mon, 05 Mar 2018 02:17:56 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!e10no1314304itf.0!news-out.google.com!a25ni3808itj.0!nntp.google.com!e10no1314300itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Mar 2018 02:17:56 -0800 (PST) In-Reply-To: <0c90fa0c-4b3d-4c96-b6c6-5c72bdcf2866@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:7466:f44c:da21:40b1; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:7466:f44c:da21:40b1 References: <90838aa0-bd51-4913-b0cf-1ded5024c151@googlegroups.com> <0c90fa0c-4b3d-4c96-b6c6-5c72bdcf2866@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: multiple delay alternative From: Robert Eachus Injection-Date: Mon, 05 Mar 2018 10:17:56 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:50815 Date: 2018-03-05T02:17:56-08:00 List-Id: On Sunday, March 4, 2018 at 11:08:25 PM UTC-5, Bojan Bozovic wrote: > Delay will simply stop execution (not schedule the task) for an amount of= time until the condition needed is met, and then process the task entry. This is one of those confusing statements of reality that looks like it say= s something special. If the delay expires and all processors are running h= igher priority tasks, the delayed entry call continues to wait, but now for= reasons of priority. When trying to understand what is going on, you can normally divide the tas= ks in a program into those that make entry calls, and those that accept ent= ry calls. (Yes, task initialization may do the opposite to start up a set = of worker tasks.) Now: > If you have both delayed and non-delayed entries for the same "accept" in= "select" non-delayed will be executed (as far as I can tell)... > select=20 > entry_call_alternative=20 > or=20 > delay_alternative=20 > end select; >From the calling side, this is the only delay alternative. It says to wait= on the entry for N seconds, then give up if the entry is not available in = that time. Tasks that are waiting to be called can have multiple accept statements ava= ilable--this is the selective accept. Looks similar, but it is on the acce= pting side. Notice that one of the most common uses of the selective accep= t is to have a terminate alternative. This results in an orderly shutdown = of all waiting tasks. Yes, if you don't need orderly, or need an emergency= shutdown you can use an abort statement. The important thing to remember is that tasks come in these two flavors, ca= llers and servers. There is an important subset of server tasks which alwa= ys runs (once created) in the calling task's thread of control. These have= mostly been replaced by protected objects. Oh, and sometimes you have worker tasks, which call an entry to get a work = unit, eat up a chunk of CPU time, call an entry to deliver results then go = back to the original entry call. There are several ways to shut these down= , but I haven't found a (non-ugly) version that uses a terminate alternativ= e. (Aborting the whole group of worker tasks when all the work is done is o= ften the most practical.)