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: a07f3367d7,385c146dd3112519 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 Path: g2news1.google.com!postnews.google.com!j31g2000yqa.googlegroups.com!not-for-mail From: Martin Newsgroups: comp.lang.ada Subject: Re: Private or public task ? Date: Wed, 10 Feb 2010 00:40:22 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <38a0a3f9-b4a0-48f3-98c9-63b03fe03aca@q4g2000yqm.googlegroups.com> <8bf887ec-38cc-4327-8cf6-38af4925e786@a5g2000yqi.googlegroups.com> NNTP-Posting-Host: 20.133.0.8 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1265791224 23534 127.0.0.1 (10 Feb 2010 08:40:24 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 10 Feb 2010 08:40:24 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: j31g2000yqa.googlegroups.com; posting-host=20.133.0.8; posting-account=g4n69woAAACHKbpceNrvOhHWViIbdQ9G User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9072 Date: 2010-02-10T00:40:22-08:00 List-Id: On Feb 10, 8:29=A0am, Hibou57 (Yannick Duch=EAne) wrote: > On 10 f=E9v, 09:17, Maciej Sobczak wrote:> > = There are two kinds of blockings: bounded and unbounded. The idea is > > > that when computing a time budget, you can account for bounded > > > blockings, but not unbounded ones. > > > The "potentially blocking" phrase should be understood as really mean= ing > > > unbounded. > > > Well, I know what you try to convey, but there are traps: > > > =A0 =A0delay Some_Static_Constant; > > > Is it bounded or unbounded? > > > As far as WCET (or any other time-based analysis) goes, the above can > > be accounted for statically. Still, it is a no-no within any protected > > operation. > > Interesting enigma > > I would say Bounded, as it is predictable. > ... as long as the delay is short, otherwise it will break the other > rule stating that a protected operation should be fast to execute. > > If I try to have a delay X.Y in a protected operation, GNAT just warns > me =93 potentially blocking operation in protected operation =94, while > the program is still compiled. > > You've said =93 it is a no-no within any protected =94 : do you get a > compilation error when you do the same ? > > I've not seen anything in the Rationale nor in the ARM which > explicitly disallow it anyway (but as these are long pages I should > later read again, I may have miss it). It's isn't predicatable - it will delay for /at least/ Some_Static_Constant. It's up to the task scheduling algorithm (plus the rest of the program! ;-) as to what happen next...and when! Cheers -- Martin