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!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!news-peer.in.tum.de!lrz.de!not-for-mail
From: Sebastian Hanigk <hanigk@in.tum.de>
Newsgroups: comp.lang.ada
Subject: Re: [Ravenscar] run tasks on events
Date: Fri, 30 May 2008 10:57:03 +0200
Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Message-ID: <g1ofgv$qgg$1@news.lrz-muenchen.de>
References: <g1katv$b8r$1@news.lrz-muenchen.de>
 <483fabe3$0$23819$4f793bc4@news.tdc.fi>
NNTP-Posting-Host: kelvin.fs.tum.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.lrz-muenchen.de 1212137824 27152 129.187.202.43 (30 May 2008
 08:57:04 GMT)
X-Complaints-To: newsmaster@lrz-muenchen.de
NNTP-Posting-Date: Fri, 30 May 2008 08:57:04 +0000 (UTC)
Mail-Copies-To: never
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (darwin)
Xref: g2news1.google.com comp.lang.ada:466
Date: 2008-05-30T10:57:03+02:00
List-Id: <comp.lang.ada>

Niklas Holsti <niklas.holsti@tidorum.invalid> 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?

> Note that under the Ravenscar profile, one generally needs one
> protected object per (sporadic) task, anyway, to trigger that task
> when required. This protected object can easily be extended with a
> boolean control variable such that the entry triggers the task only in
> the appropriate modes or phases.

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.

> On the other hand, personally I'm a bit skeptical about triggering
> certain tasks only in certain modes. I suspect that most systems could
> as well keep the same set of active tasks, and just make the tasks do
> different things in different modes, using plain old "if then else" in
> the task body.

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.


Thank you for your help!

Sebastian