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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!news.stack.nl!cs.uu.nl!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ravenscar and context switching for Cortex-M4
Date: Sat, 14 Feb 2015 00:45:04 +0100
Organization: A noiseless patient Spider
Message-ID: <mbm28q$is8$1@dont-email.me>
References: <ba36d86a-cfb6-475f-9cec-12f1cbb39087@googlegroups.com>
 <ck4k7iFmom0U1@mid.individual.net> <mbkrbq$v3o$1@dont-email.me>
 <ck6ssiF9shvU1@mid.individual.net>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 Feb 2015 23:44:26 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
 logging-data="19336"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1/2oL4a/52W+yFJyWH/IHANthzuKux5Jfw="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <ck6ssiF9shvU1@mid.individual.net>
Cancel-Lock: sha1:09ejZFqyD8584WfrerJFFnQ5pi0=
Xref: number.nntp.giganews.com comp.lang.ada:192271
Date: 2015-02-14T00:45:04+01:00
List-Id: <comp.lang.ada>

On 13.02.15 19:08, Niklas Holsti wrote:
> On 15-02-13 14:41 , G.B. wrote:
>> On 12.02.15 22:28, Niklas Holsti wrote:
>>> On 15-02-12 22:25 , Patrick Noffke wrote:
>>
>>>> According to
>>>> http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_predefined_profiles.html#ada-restrictions-in-the-ravenscar-profiles,
>>>>
>>>>
>>>> at most one task may be queued on an entry.  I take this to mean *on
>>>> a single entry* and that two tasks may be simultaneously queued on
>>>> separate entries.

> Two or more tasks can be simultaneously queued (i.e. blocked) on separate entries, as long as no more than one task is queued on any given entry. These separate entries must be in as many separate protected objects, because each PO can have at most one entry.

I guess I had misread "simultaneously queued on separate entries"
to mean the separate queues of a PO with multiple entries.
Likely because if going to the stadium, "standing in queues at
separate entries" won't usually make me think of one queue being in
Liverpool, Anfield and the other in Barcelona, Camp Nou.
I'm sorry. It now will.