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,7b6ebbd3cbca32ce X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!feeder.news-service.com!newsfeed.freenet.de!bolzen.all.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!citadel.nobulus.com!fi.sn.net!newsfeed1.fi.sn.net!news.song.fi!not-for-mail Date: Fri, 30 May 2008 13:47:14 +0300 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [Ravenscar] run tasks on events References: <483fabe3$0$23819$4f793bc4@news.tdc.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <483fdadf$0$2672$4f793bc4@news.tdc.fi> Organization: TDC Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1212144351 news.tdc.fi 2672 81.17.205.61:32934 X-Complaints-To: abuse@tdcnet.fi Xref: g2news1.google.com comp.lang.ada:468 Date: 2008-05-30T13:47:14+03:00 List-Id: Sebastian Hanigk wrote: > Niklas Holsti writes: > > >>Anh Vo wrote: >> >>>It is not true. Protected entry, implemented in Transient >>>Signals for example, can suspend/release multiple tasks. >> >>True in unrestricted Ada (an entry queue can hold many tasks), false >>under the Ravenscar profile (maximum one task waiting on an entry). If >>you use protected objects to trigger tasks, you need one object per >>task. > > > Argh. Seems I was too early in my reply to Anh Vo ... > > Shouldn't there be a constraint error? Acccording to LRM D.7.19(1/2), violation of Max_Entry_Queue_Length raises Program_Error at the violating entry call. In unrestricted Ada, if an exception occurs in a task, and the task does not handle the exception, the task by default terminates silently when the exception propagates out of the task. If you want to know about exceptions in a task, you should put a last-chance, catch-all exception handler in the task body ("exception when others => ..."). Since the Ravenscar profile contains the restriction No_Task_Termination, by LRM D.7.15(1/2) it is implementation defined what happens when a Ravenscar task terminates due to an unhandled exception or for other reasons. It may be reported or signalled in some way, or not. > I hadn't included the Profile pragma in all my source files, so I'm > assuming that the successful test earlier on was due to not complying > with the Ravenscar profile. Having put the pragma directives into the > source code, now only one of the waiting tasks resumes/suspends. The Profile pragma is a "configuration" pragma. If you use Gnat, you should normally put configuration pragmas in a separate file called "gnat.adc", and Gnat will then include them in all compilations. See the GNAT User Guide; I haven't used such pragmas myself, so I'm not expert. > Well, I found the signaling/scheduling concept very elegant; now it > seems my best bet would be a check inside each task's loop if the > respective conditions evaluate to True, otherwise simply delay until the > next period. That is a good solution for periodic tasks, where the task is triggered by "delay until" and not by an event. Of course you will waste some processor time on unnecessary activations of the task. To avoid that, make the task suspend itself on a suspension object (a different object for each task) when the task has nothing to do. The "elegance" of this solution is subjective, of course, but I don't find it very ugly to have a different object for each task; it even makes it easier to select the subset of tasks that should become active. Note also that transitions between phases or modes must be planned and implemented carefully, perhaps over more than one task cycle, to avoid transients (both control transients and performance/deadline transients) during the transition. HTH, -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .